release-docs

Until August 22nd 2024, we managed our release documents manually in the addons repository (see release-docs.rst).

Currently, addons-server is the only repository deploying via github releases.

Creating a new release

To create a new release, use the draft release workflow.

This will create a new draft release in the repository. This release can be updated with instructions and things to note for the next push. You need to set the push hero (see push-duty for the rotation) as the assignee for the draft release. You also need to specify the next push date. This will be roughly 2 weeks after the current push. The exact date will correspond with the next jira sprint.

Publishing a release

During the tag, we can trigger a staging deployment for addons-server by publishing the current draft release that should have been created at the end of the last push. It will likely be the first release in the list and will match the current push tag date.

In order to publish the release, click the edit icon at the top right of the release card.

• Update the release notes by clicking the Generate release notes button.

• Publish the release by clicking the Publish release button.

• Include the compare link for addons-frontend. See tagging for details.

Warning

Make sure that the release is tagged as “latest”. This is the default behavior but don’t accidentally un-check it.

Publishing a release will trigger the release workflow.

The workflow will:

• generate a tag for the release based on the specified tag (should use the date timestamp see tag-services)

• run our full CI pipeline on the tag

• trigger a stage deployment for the tag

Failing CI

Github unfortunately does not link workflows to releases that triggered them. You can inspect Failed CI to see workflows triggered by a release event that failed.

Tip

We should include slack notifications for failed CI, especially on deployment triggering workflow runs.