feat: publish official docker images on release #12828
Conversation
|
The new PR pipeline isn't running here due to the settings of the repo not allowing to run newly added actions without approving them first (which is good!), IDK if you as maintainer have an option to run newly added actions here if you want, otherwise if you want to see examples you can look at my repo: https://github.com/maybeanerd/mage/actions/runs/10760332986 |
|
@JayDi85 just saw you do a version bump 👀 (eeada90) (edit: ah well it also was the release then, unlucky) |
|
I’ll research it and integrate later. |
|
awesome! I saw too late that the release also had happened, I thought I could sneak this in before 😁 |
|
Another release without official image 😢 |
This creates an image with hardcoded version of the contained mage for testing. Afterwards a process needs to be defined to either pass the version onto the container whenever a release triggers it, or actually build from source.
* feat: build image from source * attempt to use latest maven to build * Update Dockerfile * fix: move unzip to final image * style: format Dockerfile * fix: typo in envvar * feat: provide usable docker-compose - both usable for local development, as well as deployment (to copy paste and work off of) * refactor: rename envvars
|
Very interested in this :) I made one a while back that grabbed the current version by scraping the version from HTML...this would be better! |
|
@JayDi85 hi, any plans on when you will take a closer look at this? |
|
@JayDi85 hoping to bring you attention to this, including it would be really helpful and this PR appears thoroughly safe :) |
|
@maybeanerd FYI I've been using this and it's been serving me well! |
That's great to hear! ❤️ We've also been exclusively using our own instance running the image since I first opened this PR, and it works perfectly. |
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.