ci: release automation

[davidspek]

Closes: #4025

This PR adds automation for generating release as described in #4025. Semantic Release is set to run when it is manually trigger, with it intended to be scheduled to run monthly in the future. Some tests of the release automation and how it will behave exactly can be found on my fork.

It also configures the current build github action to push to GHCR on PRs, which should make testing changes from a PR easier for contributors since they can simple deploy the image that's built for them.

[Jamstah]

I think we should start with "on tag".

How do rc/beta releases work?

[davidspek]

Semantic release is the one that creates the tag (and GitHub release). It is possible to have semantic release create a tag, and then have the build be triggered by that. However, this can leave broken release where the release is created but the images aren't pushed (although I'm not sure how the release artifacts would work here).

I'd appreciate if you can also have a look at https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration. That describes how rc/beta releases work and can be configured. I'm still in the process of figuring out what the best setup for this will be and appreciate any help and input.

[Jamstah]

Right, I guess by "on tag" I really meant I don't think we should start with an automatic monthly release. We should be building main into :edge/:main, and be able to trigger 3.0.0-rc1 manually. When we get to a stable state we could consider monthly.

[Jamstah]

Looking at the doc, I guess we would need to cut the 3.x branch and use:

"branches": [{name: "release/3.0", range: "3.0.x", prerelease: "beta"}]

[Jamstah]

Playing with it all in your org might be best for now. I guess you can manually trigger the release action in the GitHub UI?

[davidspek]

The v3 release (and the default release branch) will be main. For maintenance release we can create new branches off of tags as needed. I'm just not sure how that will work with pre-releases in a more dynamic way. However, I do think we'll likely only need alpha, beta and rc for major versions so it shouldn't come up very often. Major versions are also kind of covered by next and/or next-major. So I guess creating the v4.0.0-alpha.1 release would be done by merging the next or next-major branch into the alpha branch.

I've just started playing with creating an alpha, beta, and rc branch and seeing how the releases go for that.

The workflow can be manually triggered from the GitHub UI:

[Jamstah]

Why wouldn't we make a 3.0 release branch? Isn't that where we would want fixes/patches?

3.1 would be for features, so after 3.0 is released, main would become 3.1.

[davidspek]

We don't need to create a release branch until we have a reason to backport something. For example:

• v3.0.0 is released from main
• a fix is pushed to main releasing v3.0.1
• a new feature is pushed to main releasing v3.1.0

Now a CVE is discovered that we want to backport to v3.0.x users

• A fix for the CVE is pushed to main releasing v3.1.1
• We create the v3.0.x branch from the v3.0.1 tag
• The fix is pushed to the v3.0.x branch releasing v3.0.2

So we don't need to pre-create release branches for backporting fixes, they can get created once they are needed. I think that will also make the Git tree more understandable.

[Jamstah]

OK, I can see how that would work.

We should decide what level of patching we support. Will we support 3.0.x after 3.1.0 is released?

[davidspek]

If we adhere to proper SemVer I don't think that would be necessary, since a minor version only includes new features. We might still want to support patch fixes for whatever reason, since the release automation is setup to be able to.

[Jamstah]

Is there a pr gate that stops a FEAT going into a patch branch?

[davidspek]

FYI, first successful test release has worked. https://github.com/DavidSpek/distribution/releases.

There isn't a PR gate, but semantic release will give the EINVALIDNEXTVERSION error which should block the release.

[Jamstah]

Isn't it too late once the commit is in the branch, unless we start to allow force push to remove it?

[davidspek]

Good point. Need to check how you deal with that exactly. I do remember reading about that in the semantic release docs somewhere.

[Jamstah]

I guess something like dry-run for prs? https://semantic-release.gitbook.io/semantic-release/usage/configuration#dryrun

[davidspek]

I'm already using dry-run in the release so we can get the version to build the artifacts with, then they get built, and afterwards it runs without dry-run. However, it might be a good idea to run semantic release dry-run on PRs to catch bad merges into branches. I'll need to test and see what it does exactly with a bad commit in a PR.

Also, this seems like it might have some interesting info in it. https://shinesolutions.com/2021/07/21/learning-to-use-semantic-release-the-hard-way/

[davidspek]

@milosgajdos @Jamstah @thaJeztah @wy65701436 @deleteriousEffect What needs to be done to get this over the line?

[crazy-max]

This workflow is not needed imo, The metadata-action in build workflow already sets the right tags based on semver: https://github.com/docker/metadata-action#typesemver

[crazy-max]

Why a new workflow? This adds so much fragmentation. Build workflow already handles properly pr,push,tags events and sets the right tags based on these events through the metadata action: https://github.com/docker/metadata-action#typesemver

See for example latest beta tags: https://github.com/distribution/distribution/actions/runs/7264017733/job/19790726671#step:3:54

[crazy-max]

I'm not sure why we would need this workflow? Do we not trust GH events?

[crazy-max]

Don't think this is needed for this PR. I think we should use dependabot to update actions.