Server release workflow

[Protonull]

When there's a new release of MapSync, there's a workflow that automatically builds and uploads the mod jar to it, but there's no equivalent for the server, Docker or otherwise. Currently, if someone wants to start using MapSync, they'd be downloading the v2.1.0 mod from the releases page or from Modrinth, but the README instructions would have them cloning the latest (v2.2.0-SNAPSHOT) version of the server, which has since switched to websockets amongst other protocol changes.

We should add a workflow that also uploads artefacts for the server for each new release. I'm not sure about the Docker side of things, but there's the still-experimental SEA for node24. But has SFE. There's pkg but it's no longer maintained.

[Protonull]

Seems like there's already a Docker publish workflow (https://github.com/CivPlatform/map-sync/pkgs/container/map-sync/versions?filters%5Bversion_type%5D=tagged), though I haven't tested it.

[Huskydog9988]

You can view the container here. Basically all that needs to be done is update the docs to use the versioned Docker image instead of cloning the repo.

[Protonull]

Yup, though would it be possible to upload some kind of artefact to the release itself, even if it's just a text file containing the docker pull command for that specific release version? Having two different release locations is bound to be confusing.

[Huskydog9988]

I think it would be reductive to put that into the release itself. IMO, should probably just do a docs folder or something and explain it there if you really wanted to. Could even throw together a basic docs site too if you really wanted based on that with vitepress or something.

[Protonull]

I dunno, I feel like having everything in a single, findable place is important, but I don't think a docs website or folder is the way to go it'll likely go unmaintained; having it be a result of an automatic workflow has the benefit of being automatic (a revelation, I know).

Is it possible though? Is it possible to add something to the docker.yml workflow to upload a text file to the release that's docker pull <version> with the version filtered somehow to what the workflow just uploaded to Github Packages?

[Huskydog9988]

I mean at that point just explain how docker tags work to the end user, and even then you still wouldn't need to include that line because its implicitly understood.

[Protonull]

You say that, but I highly suspect that #140 is related to this. I can't cannot say for sure as they've yet to respond, but their issue precipitated this one - and if I'm correct in my assumption, then that would contradict your assertion. I still maintain what I said here in that MapSync should be as user-friendly as possible (the issue there has since been resolved by just having mod users manually specify ws:// or wss://). In my opinion, we shouldn't assume or expect MapSync server operators to have any sysadmin experience.

[Huskydog9988]

140 is because we tell people to clone the git repo, and then that builds the servers on the local machine. The provided docker compose makes zero reference to the prebuilt container image.

[Protonull]

Yeah, and the README should be updated, but I think everything should be as centralised as possible. For example, if we started taking advantage of nodejs's SEA feature to produce executables (which iirc has been discussed before), those executable would be uploaded to the Github release, right? I don't see why references to the relevant docker image should be excluded from that.

[Huskydog9988]

Uploading binaries as part of the release is a versioned binary file that is part of the release. Now, if you wanted to upload the raw OCI image as a release artifact, it would make more sense then a txt doc on each release saying "pull ghcr.io/asfadsfaf:v123456"

[Protonull]

Yeah, I'd much rather have the image in the release instead, if possible. I really do feel like having everything together in one place is really important.

[Huskydog9988]

Orin, I said that as a joke. I know you don't get docker, so please just trust me on this, it's a terrible idea. The part of the point of a container registry is that you can pull only the parts of the image that change, instead of downloading the full binary file each time. Also basically nobody knows how to do it with raw files since its such an exotic use case.

[Protonull]

Then please fix whatever is causing people to get confused... because people are getting confused.

[Protonull]

Presume resolved via #143