The end-to-end tests will always fail when more than one release is
broken. When trying to fix one, the other will get in the way and vice
versa. The only way to get out of this deadlock is to replace all
broken releases but one by doing the following on forgejo-integration:
* set SKIP_END_TO_END to true in the actions vars tab
* pushing a commit to the corresponding branch, fixing the problem
It could be used but then `cp --dereference` would need to be used instead in
the forgejo-build-publish action.
+ docker cp forgejo-amd64:/app/gitea/forgejo-cli forgejo-9.0-test-linux-amd64
+ chmod +x forgejo-9.0-test-linux-amd64
chmod: cannot operate on dangling symlink 'forgejo-9.0-test-linux-amd64'
- detect changed files for the run
- let e2e files specify which related files they "watch"
- only run e2e tests based on pattern matching or when generic files
change
- fallback to full runs if env not specified
ci: cache frontend build across jobs
ci: ensure caches are saved with zstd
work around https://github.com/actions/cache/issues/1169
ci: require unit tests for remote cacher
- prevents unnecessary runs in case the unit tests already fail
- starts the integration tests about 2 minutes earlier
- should give some overall speedup to the CI run, because the long integration tests are run and finish earlier, and the cacher tests should still usually finish in time
- does not save any computing resources, just provides quicker results when runners are not under high load
- retrieved by the commit hash
- removes bindata tags from integration tests, because it does not seem
to be required
- due to the missing automatically generated data, the zstd tests fail
(they use repo data including node_modules (!) as input to the test,
there is no apparent reason for the size constants)
includes:
- easier repo declaration for playwright tests by @Gusted
- full backend build for pushing Git repos by @Gusted
- playwright testing (which fails with the current diff algorithm, but
passes with the new)
- disable eslint rule for conditional expect, because it defeats the
purpose (working around it would result in much more complex test code
in our cases)
When the Forgejo CLI binary is `forgejo-cli`, the `--verbose` or `--quiet`
arguments are available globally for all sub-commands. The same
sub-commands can be used with `forgejo forgejo-cli`, those flags are
not available.
If the tag of a stable release is removed from integration, it won't
be properly described when building the test release. It will be:
8.0.0-dev-1648-7b31a541c0+gitea-1.22.0
instead of:
8.0.1-5-7b31a541c0+gitea-1.22.0
The releases are created when:
* a tag is pushed to the integration repository it will create a
vX.Y.Z release
* a new commit is pushed to a branch and mirrored to the integration
repository, it will create a vX.Y-test release named after the branch
When both vX.Y.Z and vX.Y-test release are present, the end-to-end
tests will use vX.Y.Z because it comes first in release sort
order. This ensures that a last round of end-to-end tests is run from
the release built in the integration repository, exactly as it will be
published and signed.
In between stable releases, the vX.Y-test releases are built daily and
must be used instead for end-to-end testing so that problems can be
detected as soon as possible. For that to happen, the stable release
must be removed from the integration repository and this is done 24h
after they were published.
The vX.Y-test releases are removed if they have not been updated in 18
months. As of August 2024 it is possible for a LTS to still be needed
in tests over a year after it was last updated, although it is
unlikely that such a lack of activity happens, there is no reason to
remove the test release before that.
* specify the version targeted by the pull request. The end-to-end
tests previously compiled all known branches which was a waste. The
pull request now must specify which version it is targeting so that
only this version is recompiled and used for testing.
* when building the daily releases, use the release from the
integration organization to ensure the tests are run against the
latest build. Clarify in a comment why the lookup order of
organizations is reversed in this particular case.
Refs: https://code.forgejo.org/forgejo/end-to-end/pulls/239
Upgrade to release-notes-assistant 1.1.1:
* multiline release notes drafts were incorrectly categorized
according the first line, instead of for each line
* when there is a backport, link the original PR first
* remove spurious </a>
Forgejo sets a label and will notify this when opening the pull
request. Triggering when it opens will make two workflows for the same
SHA. Re-opening is a border case that is not needed.
* if <!-- is inserted just after a <!-- --> it will not render
well, it needs to be separated by a newline
* do not use ? in sed -E, it is not the same as with JavaScript
GITHUB_TOKEN does not have permission to write the repository and is
not allowed to edit or comment on pull requests because of that. A PAT
from a regular user who does **not** have permission to write to the
repository either but who is in a the contributors team will have
permissions to do that because there is a "write pull request"
permission given to the team.
If the 'worth a release-note' label is set, add a release note entry
to the description of the pull request as a preview.
* use the `release-notes/<pr-number>.md` file if any
* otherwise use the pull request title
Refs: https://code.forgejo.org/forgejo/release-notes-assistant
When a new go version is published, it takes about 24h for
https://github.com/actions/go-versions to be updated (see
https://github.com/actions/go-versions/pull/102 for example).
In the meantime the setup-go action that depends on it will install a
version of go that fails golang.org/x/vuln/cmd/govulncheck.
Move the security check to be the last step of the test job instead of
the first. It will still block the PRs from being merged but it will
allow the PR authors to keep working and look at the test results in
the meantime.
Fixes: https://codeberg.org/forgejo/forgejo/issues/4294
For #4082.
~~Per the discussion in the issue, the current plan will likely involve duplicating the redis library calling code once for each cacher, as neither garnet nor redict guarantee continued compatibility with redis.~~
See discussion below for details.
## Tasklist
- [x] Write workflow to run cache-specific unit test(s) only (cache, session, queue, nosql) for each cacher
- [x] Check whether garnet and redict pass unit tests with no code modification (gauge required work)
- both passed, but that is because there were very few tests that test the remote cache store
### Out of scope for this PR
- Improve test coverage
- `modules/cache` against a server
- `modules/session` against a server (also needs tests in general)
- _(?) Duplicate implementation for each cacher_
- _Restructure redis usage in `modules/cache` and `modules/settings/cache`_
- _Restructure `modules/session` and its settings_
- _Restructure `modules/queue` and its settings_
- _Restructure `modules/nosql` and its settings_
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4138
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Elias Elwyn <a@jthv.ai>
Co-committed-by: Elias Elwyn <a@jthv.ai>
