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: publish official docker images on release #12828

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

maybeanerd
Copy link

@maybeanerd maybeanerd commented Sep 8, 2024

this fixes #12748

This PR adds a few things:

  • a docker-compose and Dockerfile to build the server from source and then be able to deploy with the resulting image
  • pipelines to build and publish this image whenever a tag is pushed (this happens when a GitHub release is made, e.g.)

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.

@github-actions github-actions bot added the dev label Sep 8, 2024
@maybeanerd
Copy link
Author

maybeanerd commented Sep 8, 2024

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

@maybeanerd
Copy link
Author

maybeanerd commented Sep 9, 2024

@JayDi85 just saw you do a version bump 👀 (eeada90) (edit: ah well it also was the release then, unlucky)
If we could get this merged before the next upcoming release, that'd be awesome! This solution doesn't yet support a nice way to build past versions (although I can also work on providing that later on)

@JayDi85
Copy link
Member

JayDi85 commented Sep 9, 2024

I’ll research it and integrate later.

@maybeanerd
Copy link
Author

awesome! I saw too late that the release also had happened, I thought I could sneak this in before 😁
Take all the time you need

@maybeanerd
Copy link
Author

Another release without official image 😢
Ill rebase my main branch again to release the latest version from my fork (but im not actually changing the diff of this branch 👍🏻 )

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
@justinshaw
Copy link

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!

@maybeanerd
Copy link
Author

@JayDi85 hi, any plans on when you will take a closer look at this?
It's totally fine if you don't have the time for it in the near future, I just felt like you communicated "soon, don't worry" and now it has been quite some time 😁 If you intend to not look at this for quite some time, please say so

@justinshaw
Copy link

@JayDi85 hoping to bring you attention to this, including it would be really helpful and this PR appears thoroughly safe :)

@justinshaw
Copy link

@maybeanerd FYI I've been using this and it's been serving me well!

@maybeanerd
Copy link
Author

@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.

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

Successfully merging this pull request may close these issues.

feat: official docker images
3 participants