feat: publish official docker images on release

[maybeanerd]

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.

[maybeanerd]

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]

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

I’ll research it and integrate later.

[maybeanerd]

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]

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 👍🏻 )

[justinshaw]

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]

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

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

[justinshaw]

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

[maybeanerd]

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

[maybeanerd]

@JayDi85 hey, any news on integrating this?

[JayDi85]

@Grath can you describe your current CI/CD build and release process? Docker, manual steps, etc.

[Grath]

I've been running my own builds because I want to get the latest cards and updates and the beta update cadence is too slow for my tastes.

I have a Python script that I run on my home Linux server that

• Goes to a clean copy of the Github repo (other than setting a different version so people can't join servers with incompatible versions)
• Pulls the latest commits
• Runs the 'build and package' perl script
• Moves that packaged release out of the clean repo and renames it to include the date and time the build was made
• Builds a config.json that points to where that build will be located as a build artifact on Github
• Pushes config.json to a Github Pages enabled repository (note: this is not recommended, and Github might get mad at you if you do this at scale; you should host your own config.json preferably, I get away with this because I don't run a public server and so most of the people using my builds are a handful of my friends who play with me.)
• Uses Github's command-line utility gh release create {release_name, date in my case} --notes "Automatic release for {date}" mage-bundle-{date}.zip to create a release on that same repository (should probably make it a release on my fork of XMage but this was a hack job I did and I've been too lazy to fix it to do things properly) with the packaged release as a build artifact, which you can see at https://github.com/grath/grath.github.io

This script is mostly using subprocess to run shell commands so it should probably be a Bash script instead of Python but I know Python a lot better than I know Bash.

After I push a build, I go manually close my server, update XMage via the launcher, and relaunch with the new version.

I'm not using any docker in my system (I just manually run my private server via a shell script) but the only manual steps per release are

• running the Python script (my cron job to do releases hasn't been working and I haven't bothered figuring out what's wrong and fixing it, I just run a release before I go to bed on Thursday or Friday morning/early afternoon in advance of my usual playgroup meeting on Friday nights)
• Updating the version and fixing the merge conflicts after JayDi does a new release.

Bonus: Hosting the releases directly on Github means that the update process is substantially faster than xmage.today updates due to the speed at which the files can be downloaded.

[maybeanerd]

I don't quite understand what's the point you're trying to make here by bringing this workflow up?

This seems like it solves something very different, as my PR adds image releases to the "official" stable release versions , and your solution is neither containerized, nor fully automated, nor follows the stable release pattern.

What you describe makes sense, but solves an entirely different issue IMO

[Grath]

Yeah, my workflow solves my issue (bypassing JayDi's inconsistent and infrequent update cadence) and is entirely unrelated to container solutions. No idea why JayDi asked me to talk about it here, but I laid out what I'm doing as requested.

[JayDi85]

I thought Graph used automatically scheduled builds (once per week).

XMage must have two "release" channels:

• dev channel for scheduled releases (once per day);
• stable channel for manual releases with what's new docs;

And docker builds must be a main part in both use cases, not custom scripts like nowadays.

[Grath]

Yes, that's what I've been experimenting with, but this PR isn't about building new builds of XMage. This is about building an official Docker image for XMage, and doing a new image automatically when there's new releases.

[maybeanerd]

We could run the pipeline I prepared here on a weekly or daily schedule as well. That should be very straight forward, we just need a bit of changes to determine the tag then

Should I propose the necessary changes in this PR, or could we stagger it? (Meaning first merge this, then add more later)