Ostranauts release pipeline
I use GitLab CI to check my Ostranauts mods and build their install ZIPs. Version tags create a GitLab release with a link to the ZIP.
- Filed under
- DevOps
- Built with
- GitLab CI, Python, Podman
- Date
- Links
- Code
I’ve been using my Ostranauts mods to learn more about CI/CD: checking changes automatically and building a download when I tag a release.
What runs
Branch pushes and merge requests run a Python helper that checks the mod’s JSON and version numbers. For mods with a plugin, the mod and plugin versions have to agree, and a release tag has to match them. That catches version mix-ups before anything gets packaged.
A version tag
such as v0.3.3 starts the build and creates a GitLab release with a link to the
install ZIP. Using tags gives me a separate step to decide when something is
ready to release. I use the same Python helper
locally and in CI, so there’s one packaging process to maintain.
Building the plugins
Bigger Thrusters and Put On Your Suit need libraries from my copy of Ostranauts to compile. I run those builds with the .NET 8 SDK on a private GitLab runner, the worker that picks up the build job. It runs in a Podman container without root access, with the game libraries mounted read-only. Those libraries stay out of the repository and the download.
GitLab keeps the ZIP as a job artifact, a saved output from that build. The release links to that particular job, so a later build doesn’t change which ZIP an older release points to.
These checks catch data and packaging problems. I still have to check how the mods behave in the game.