feat(infra): Publish Docker image on release

[Alex-deVis]

The post-release job will trigger the publish-docker-image job which builds and pushes the image to the GitHub Container Registry (ghcr.io). The image is tagged with the semver tag and latest.

Regarding #427 (comment), even a focused image can be helpful for local development and testing. I think it would be beneficial to start publishing the image even if it might change in the future.

I tested these changes on my fork:

• the publish-docker-image action
• the resulting image is under packages

Fixes: #427

[epage]

At my quick glance, this seems very different than the workflow from #1116. As the person purposing this alternative workflow, could you step through why you made different decisions?

[Alex-deVis]

Hello, @epage, thanks for taking the time to review! My PR only addresses building the docker image on release to be able to run the action locally similarly to how it is run on GH actions pipeline. I have no interest in updating the Dockerfile. Therefore, you could say that the PRs are complementary; in my view, changes on Dockerfile should be separated from changes on actions.

The backbone for my changes is this guide from GitHub. Let's dive into my changes:

• the trigger is the completion of post-releaes workflow. I think this is cleaner than release: published since creating a release consists only of creating the page, without any other validation. Bundling the completion of post-releases with the creation of the Docker image ensures that you'd only do it when everything is set and done.

• Extract tag from master step is needed because we use the post-release completion as the trigger. We have to determine the latest tag ourselves since the trigger is not tied to a tag or a PR. git tag --merged ${{ github.ref_name }} checks the latest tag on the master branch since that is where releases will be.

• Extract metadata (tags, labels) for Docker step adds the previous tag (type=semver,pattern={{version}},value=${{ env.TAG }}) and latest (type=raw,value=latest,enable={{is_default_branch}}) to the list of tags.

[Alex-deVis]

Hi, @epage! Bump on this.

[epage]

Please don't bump. I have a queue I'm working through, made worse from the holidays, and this creates extra noise.

[Alex-deVis]

Hi, @epage, I respect that you have a list and requested not to be bumped on updates. The PR remained stable and requires minimal feedback to go forward and add an essential feature.
To refresh your memory:

• The PR will create a docker image hosted on the GitHub container registry on every release tag
• The PR follows the official GitHub documentation with minimal changes (see the referenced links and my comments)
• The PR addresses a single task, that's why is smaller than its counterpart
• For a more in-depth explanation check the above comment, or feel free to reach out to me for more context

Again, I respect your schedule and am eager to help you with information to merge this.

[epage]

That is very rude to re-bump a PR when you've already been told not to bump it.

[nogweii]

A couple of comments from a scan:

• Is it necessary to put ghcr.io into an environment variable? I think it'd likely be the only registry that a typos image gets published to, but I may be wrong.
• This doesn't appear to build a multi-arch image, so users on arm64 platforms would miss out.