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.
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
