Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(infra): Publish Docker image on release #1183

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Alex-deVis
Copy link

@Alex-deVis Alex-deVis commented Dec 15, 2024

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:

Fixes: #427

The post-release job will trigger 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.

Signed-off-by: Alex Apostolescu <alexx.apostolescu@gmail.com>
@epage
Copy link
Collaborator

epage commented Dec 16, 2024

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
Copy link
Author

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
Copy link
Author

Hi, @epage! Bump on this.

@epage
Copy link
Collaborator

epage commented Jan 13, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Not available dockerhub/external repo for dockerfile
2 participants