7
1
Fork 0
Find a file
Earl Warren 474d4c765d
release-notes: add reminder to update the milestones
specially needed for security releases when the merge happens the same day
2025-12-01 15:35:41 +01:00
.forgejo chore: improve action job names (#431) 2025-09-26 06:56:42 +00:00
templates release-notes: add reminder to update the milestones 2025-12-01 15:35:41 +01:00
.editorconfig feat: build the release 2024-12-04 00:27:10 +01:00
.gitignore add task workflow 2024-12-03 00:50:58 +01:00
build.sh build: codeberg can be slow, give it more time 2025-08-31 11:22:39 +02:00
LICENSE Initial commit 2024-12-02 17:07:34 +00:00
publish.sh publish: remove the tag in the publisher repository 2024-12-13 18:38:39 +01:00
README.md warning about setting multiple labels at the same time 2024-12-13 18:39:53 +01:00
release-notes.sh release-notes: faster and editable 2025-07-18 16:01:33 +02:00
renovate.json Add renovate.json 2024-12-03 09:00:59 +00:00
upgrade-code.sh fix: upgrade code.forgejo.org: it can happen on the day the branch is cut 2025-06-25 10:59:49 +02:00

release-manager

Tools and workflows to manage Forgejo releases

  • Each task for a release is represented by an issue and grouped in a milestone (e.g. 7.0.12). They are shown in chronological order. A workflow can be used to manually create a list of task for a given release.
  • A given task may be associated with workflow to carry out the necessary steps (e.g. the 'Announce' task workflow is announce.yml).
  • If multiple security releases must be published simultaneously, some tasks (such as 'Annouce') must only be done once for all of them.
    • The release with the lowest version number must be published first.
    • The description of the milestone of the release with the highest version number must contain the whitespace separated list of the lowest version (e.g. if the 9.0.2 milestone description contains "8.0.5 7.0.18", a single announcement will be published referencing the three releases).

Usage

Warning

visually verify the task is going to do the right thing, never assume it will.

When setting or removing a label, do it one by one, not all at once otherwise it may race.

  • set the dry-run label
  • set the run label
  • carefully review the comments posted explaining what would be done
  • remove the dry-run label
  • set the run label
  • carefully review the comments posted explaining what was actually done

Running the task helper implemented in a workflow

  • The run label triggers a task.
    • A comment is added to the issue with a link to the workflow when it starts.
    • A comment is added to the issue when the workflow completes.
    • The run label is always removed when the workflow completes.
    • The failure or success labels are set depending on the outcome of the task.
  • If the dry-run label is set, the workflow triggered by run will not have any side effect and explain what would have been done by commenting on the issue instead.

Secrets

See the wiki page of this repository for more information.

Hacking

  • Manually create a 8.0.1 milestone with issues
  • Label all issues with dry-run
  • Push to main
  • Set the run label on the issue matching the modified workflow (e.g. the Announce issue for the announce.yml workflow)
  • When finished delete all issues and the milestone