When the CI vars.ROLE is forgejo-coding, it is assumed to be the
repository where collaborative coding happens,
i.e. https://codeberg.org/forgejo/forgejo
When the CI vars.ROLE is forgejo-testing, it is assumed that only codebase
testing is to be run and no other tests such as release build
integration, label constraints, backporting etc.
When the CI vars.ROLE is forgejo-coding, it is assumed to be the
repository where collaborative coding happens,
i.e. https://codeberg.org/forgejo/forgejo
When the CI vars.ROLE is forgejo-testing, it is assumed that only codebase
testing is to be run and no other tests such as release build
integration, label constraints, backporting etc.
Notify https://code.forgejo.org/forgejo/forgejo that a new release was
published by setting the trigger label to
https://code.forgejo.org/forgejo/forgejo/issues/5.
It is only ever useful when a stable release is published, the
experimental releases are not mirrored. But it is triggered in all
cases. This will waste a few mirror check daily, when experimental
releases are built. This is an improvement compared to the current
situation where mirrors are checked hourly:
* Instead of being checked 24 times per day it will be down to less
than 5
* The mirror happens immediately after the release is published
instead of waiting for the next run of the cron job.
If a mirror operation is in progress, as evidenced by the presence of
the trigger label on the issure, it means two releases are being
published. Wait up to 1h for the mirror to complete and remove the
trigger label.
- test label needs to be set and either present, not-needed or manual
- if manual test label is set, PR description needs to contain a heading
(defined by '#') starting with "Test" (e.g. "Test instructions",
"Testing" etc)
The input to the action is not image_suffix but tag_suffix. It finds
an image and does not error. But it is the root image and the k8s
cluster needs the rootless image.
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
