Create release with template and release notes

[KevinMind]

Fixes: https://mozilla-hub.atlassian.net/browse/AMOENG-616

Description

Adds a workflow to trigger the creation of a draft release. This allows us to have a standardized template for the information in our releases.

Context

Previously we created release documentation manually and updated with commit diffs of tags and info related to a given release. Now that we can release via github releases we should automate creation of release docs in the same way.

Testing

The criteria for the release is:

• the release hero is set to the current actor. It can be updated post release but typically the release hero will trigger this workflow
• the tag is based on an input parameter which is validated:
• date YYYY.MM.DD with or without the -X suffix indicating a cherry-pick release.
• The tag is validated to not match the tag of an existing release. Cannot release the same tag twice (you can deploy the same tag twice, but that is different)
• Link to the latest published release is included.

NOTE: Release notes with commits and diffs are only created when we click the "generate notes" button. we should only do that when we actually roll out to stage.

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).
• Add or update relevant docs reflecting the changes made.

[KevinMind]

Won't recreate existing tag https://github.com/mozilla/addons-server/actions/runs/10635520149/job/29485287048

[eviljeff]

Some things I'm not clear on:

• how we're going to handle addons-frontend releases - will we just manually add the diff link in here, or something else?
• How the generated full changelog can work when there is an existing release note, with potentially important information that can't be overwritten with an entirely freshly generated release notes.

[eviljeff]

What's the YYYY.MM.DD-rcX for? It's new.

[KevinMind]

Need to support cherry pick releases. 2024.09.05-23 for example. Good catch though, I accidentally included rc in the regex.. will remove.

[KevinMind]

How the generated full changelog can work when there is an existing release note, with potentially important information that can't be overwritten with an entirely freshly generated release notes.

You generate the changelog when publishing the release. It appends the commits after any other content already on the release doc. It won't override anything.

Because releases are essentially immutable, you never change the tag on a release but create a new one, you never should need to update the changelog.

Does that clarify?

[diox]

You generate the changelog when publishing the release. It appends the commits after any other content already on the release doc. It won't override anything.
Because releases are essentially immutable, you never change the tag on a release but create a new one, you never should need to update the changelog.

There are 2 kinds of cherry-picks though:

1. Before the push to prod happened. In this scenario we tagged and deployed release A to prod 2 weeks ago, then tagged release B, deployed it to stage, but then cherry-picked before deploying B to prod. Let's call that new tag B-1. When B-1 is created, we want the companion doc to contain the diff link between the tag from A to B-1, and all previous info that was in the original doc for B. Original B tag then no longer matters and will never be deployed to prod.
2. After the push to prod happened. In this scenario we already deployed B to prod, then cherry-picked, creating B-1. The release notes should be an entirely new doc with no previous text and diff link between B and B-1.

[eviljeff]

It appends the commits after any other content already on the release doc. It won't override anything.

👍

[KevinMind]

@diox both of your proposed diffs are achievable. I don't think it will be possible to get this granular with the automation, but that is probably okay. If you are making a cherry pick release I think it is up to you to verify your target and compare tags are correct, and you can update or remove the link as you wish.

I have included info like this in the PR updating our push duty docs. Do you think this is sufficient? Or would you suggest removing the link? Or trying to make the automation support more complex linking?

[eviljeff]

r+ if @diox concurs