The milestone can only be determined to be final when a pull request
is merged.
It is possible that a pull request is opened during the development of
v10 and merged after it is published.
It is also possible that it is permanently closed without being merged.
This is a clean revert of the commits that led to grouping all jobs related to issue labeling into one workflow. The assumption that it would be more efficient was incorrect because it assumed the conditions for running each job would be evaluated statically Forgejo side. In reality the conditions are evaluated by the runner and multiplies the number of runs required instead of decreasing them. In turn, this clutters the status line of each pull request with numerous skipped runs. Finally it is more complex to maintain multiple jobs into a single workflow because the conditions for it to run have to be duplicated.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/6178
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
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.
