feat: publish official docker images on release #12828
Open
+113
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this fixes #12748
This PR adds a few things:
The pipelines run in two cases:
1. on tag/release
Whenever a tag is committed (which happens when a GitHub release is made), the pipeline will be triggered on this tag.
It will use the version the tag provides to tag the resulting image publish it on this repository using the GitHub registry. It will also tag the release as "latest" version as well.
It will build and publish both linux/amd64 and linux/arm64 variants of the image.
You can see an example of the resulting images on my fork, where I published them for testing: https://github.com/maybeanerd/mage/pkgs/container/mage
2. on pull requests
Whenever a PR is opened, it will run the image build, which will only succeed if the server can be built.
It will not publish this image anywhere.
This is IMO useful to make sure no single PR will break the entire build process of the image (which might break even if the Travis CI/CD doesn't), but the builds take time (~25mins, since its done for multiple architectures) so one could think about making this check optional before merging, or even disabling it entirely.
Since I personally prefer running these things on PRs, this proposal includes it. The nice thing is also that, since this repo is open source, GitHub gives us unlimited build minutes - so there's no fear of running out of CI/CD minutes or needing to pay at some point.