1. `playwright/test` is already installed as part of `deps-frontend` on
CI which runs before, so it's better to not install it again (on a
potentially different version), and just use the version from
package.json and add the `deps-frontend` dependency.
2. `PLAYWRIGHT_DIR` is a undefined variable, so I removed it
```bash
$ git show c8ded77680 | grep PLAYWRIGHT_DIR
+playwright: $(PLAYWRIGHT_DIR)
```
(cherry picked from commit c236e64aca42b9ab0743431bc505033a0cb78b93)
Fixes the reason why #29101 is hard to replicate.
Related #29297
Create a repo with a file with minimum size 4097 bytes (I use 10000) and
execute the following code:
```go
gitRepo, err := gitrepo.OpenRepository(db.DefaultContext, <repo>)
assert.NoError(t, err)
commit, err := gitRepo.GetCommit(<sha>)
assert.NoError(t, err)
entry, err := commit.GetTreeEntryByPath(<file>)
assert.NoError(t, err)
b := entry.Blob()
// Create a reader
r, err := b.DataAsync()
assert.NoError(t, err)
defer r.Close()
// Create a second reader
r2, err := b.DataAsync()
assert.NoError(t, err) // Should be no error but is ErrNotExist
defer r2.Close()
```
The problem is the check in `CatFileBatch`:
79217ea63c/modules/git/repo_base_nogogit.go (L81-L87)
`Buffered() > 0` is used to check if there is a "operation" in progress
at the moment. This is a problem because we can't control the internal
buffer in the `bufio.Reader`. The code above demonstrates a sequence
which initiates an operation for which the code thinks there is no
active processing. The second call to `DataAsync()` therefore reuses the
existing instances instead of creating a new batch reader.
(cherry picked from commit f74c869221624092999097af38b6f7fae4701420)
- Switched to plain JavaScript
- Tested the installation page functionality and it works as before
# Demo using JavaScript without jQuery
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
(cherry picked from commit 4e536edaead97d61a64508db0e93cf781a889472)
- Use case in `repo-commit` was tested until the point where the POST
request was sent with the same payload.
- Use case in `repo-legacy` was tested completely with comment editing.
- `jquery/no-fade` was disabled as well to stay in sync with
`no-jquery/no-fade`, had no violations.
(cherry picked from commit a5c570c1e02302212a5d8f7cf7d91f24ab0578d5)
- Switched to plain JavaScript
- Tested the wiki creation form functionality and it works as before
# Demo using JavaScript without jQuery
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit ade1110e8b7d94dc142a259854e2b73845eab8b9)
- Switched to plain JavaScript
- Tested the repo migration form functionality and it works as before
# Demo using JavaScript without jQuery
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit 100031f5f143a15c79ebbe1b77c86091e3b6d489)
Similarly to how `[repository].DISABLE_FORKS` works, lets make
`[repository].DISABLE_STARS` disable the routes too, not just hide the
functionality from the UI.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- If the user is searching repositories with an specific topic, adding
any other filter option, such as showing unrelevant repositories or
using another sort Forgejo should remember that 'topic only' was set.
- Adds integration test.
- Resolves#2461
If a documentation file is marked with a `linguist-documentation=false`
attribute, include it in language stats.
However, make sure that we do *not* include documentation languages as
fallback.
Added a new test case to exercise the formerly buggy behaviour.
Problem discovered while reviewing @KN4CK3R's tests from gitea#29267.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Based on @KN4CK3R's work in gitea#29267. This drops the custom
`LinguistBoolAttrib` type, and uses `optional.Option` instead. I added
the `isTrue()` and `isFalse()` (function-local) helpers to make the code
easier to follow, because these names convey their goal better than
`v.ValueorDefault(false)` or `!v.ValueOrDefault(true)`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Split up `repo.Action` in `routers/web` into smaller functions.
While some of the functionality was very similar (starring / watching),
they are ultimately separate actions. Rather than collecting all of them
under a single handler (`repo.Action`), split them up into smaller,
independent functions.
This does result in a little bit of code duplication, but the
independent functions should be easier to follow and understand.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The "desc" action has not been used since at least 2016, probably much
earlier. It's an ancient Gogs artifact - drop it.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- Trivial auto-fix applied.
- Removed CSS that was no longer needed (either was removed or upstream
already improved the CSS).
- Used existing variables for colors.
- Fix CSS selectors to match existing ones.
- If a `logout` event is send the user should be redirected to the
homepage, there are three mechanism that can do this. The response of
`/user/logout` and the event listener of notifications or stopwatch.
It's essentially a race for what's processed first to determine which
mechanism takes care of redirecting the user.
- Fix that the redirection mechanism of the notification and stopwatch
event listener redirects to an absolute URL.
- Ref: #2135
- If a user tries to create another protected branching rule that
specifies a set of branches already used by another rule, do not allow
it.
- Update the translation accordingly.
- Adds integration test.
- Resolves#2455
The release number displayed by the API and the CLI becomes:
7.0.0+1.22.0
instead of
1.22.0
It would otherwise be inconsistent to have different version number depending on the interface. With the current implementation `/api/forgejo/v1/version` would return `7.0.0+1.22.0` while `/api/v1/version` would return `1.22.0`. The release would be announced as `7.0.0+1.22.0` but the web API would display `1.22.0`.
It may cause some tools that are Gitea specific to not behave as they should in the future if they expect a Gitea version number and activate some features depending on what it is. They would need to be patched to strip the leading Forgejo version number before asserting the Gitea version.
Refs: https://codeberg.org/forgejo/forgejo/issues/2425
