Setting up a Godot CI/CD server

Setting up a Godot CI/CD Server

I’ve been trying out the Godot game engine, and I’m starting to really like it: Godot is pretty intuitive, it natively supports and sets up git, it’s not too hard to understand the core principles, and a growing group of creators is using it to create stuff and sharing their work.

Godot doesn’t exactly line up with how I like to do things, but usually it’s not difficult to learn.

So I decided to automate my builds!

Setting Up a Runner

I decided to make a custom self-hosted runner. It may be possible to set this up using existing tools, but I haven’t tried it myself.

This is the most intricate part.The big rocks are:

1. get the box set up set up any SSH, VPN, sudoers, etc.

2. get your tools installed: get Godot onto the box (I use flatpak), and get any other tools you need (Rust, Node, Python, etc.)

3. Install the gitlab-runner service

Once you have a Debian box on a network with access to the public internet (or your Network where your GitLab is hosted), and you have the gitlab-runner service up-and-running you can connect it to your GitLab Instance.

Debian Setup

Follow the installation net installer - it’s not too hard to get a new box up and running.

After you can log into the box, the only non-standard things you’ll need are the gitlab-runner service, and Godot. The GitLabdocumentation works perfectly.

For Godot, I found the easiest and most consistent way to get going was flatpak. The docs for setting up flatpak is here, after getting flatpak, installing Godot from flathub is pretty easy too: links here sets it up pretty well too.

Make sure you can run Godot on the box, and you’ll need to get the required binaries to build Windows (I cover this in the “Running Godot Jobs” section), but at least you can build for Windows on Debian! I don’t bother building for Mac, because people who play games don’t use Macs.

Connecting the Runner

I go with the Project Runner setup. If you want a Group Runner or other more involved set up, you should be able to take a lot of this info and run with it.

A Project runner is hands on, but simple. You assign the runner to each repository / project ad-hoc.

1. Tag the runner
2. connect the runner to a project

Once again, the GitLab documentation is great, you can follow these pages directly, starting here should mostly work, but I like to tag my runners. That’s easy enough to do by activating the runner for a project in GitLab, editing the runner, and adding tags (like “godot”).

Running Godot jobs

Once the runner is set up and connected to GitLab, it can accept jobs. I like to tag my runners with the “godot” tag, in case I get the inspiration to run mor tha. You’ll also need to get an automation job into the Godot repository.

1. Set up the build
2. add the .gitlab.yml file to your repo

Set up the build(s)

Godot has great documentation for setting this up here. Open a project, create whichever release candidates you need: for me I’m making games that ship on PC’s, so I target Linux and Windows.

Navigate to the Export menu: Project > Export

The first time you set up an export, you should see warnings about missing template and a prompt to “Manage Export Templates” should appear. Download the export templates, and once it’s done you any other project you run on the box should work.

Design the Automation Job

To make sure this will work, I’d recommend pulling he project files down and running the headless godot.

flatpak run org.godotengine.Godot --headless --export-release "Linux"

This should produce a runnable game. If it doesn’t then the automation won’t help here!

build-job:
  stage: build
  tags:
    - godot
  artifacts:
    paths:
      - my-game.x86_64
      - my-game.sh
      - my-game.pck
      - my-game.exe
  only:
    - main
  script:
    - flatpak run org.godotengine.Godot --headless --export-release "Linux"
    - flatpak run org.godotengine.Godot --headless --export-release "Windows Desktop"

This job is super slim: 1 job, runs 2 flatpak jobs and collects the expected artifacts. If you are on a larger project with several teammates, automations, and phases then you’ll probably need to add stages an steps for those phases. But this will get you off and running.

Additional Thoughts

I’m starting to like Debian more as a server / automation server. There are probably better headless distros, but Debian is solid and has all of the packages I need.

I had done something like this before using Jenkins and Ubuntu, but I want to entirely scrap that box and replace it with this going forward.

First, Jenkins is jank and old. Gitlab CI/CD is better and Jenkins should be retired.

Second, Ubuntu is just Debian but with Canonical involved, so in my opinion it’s just worse. Especially for an automation server, there’s nothing that Ubuntu can give you that Debian can’t provide.

Ubuntu has worked “fine” for the past couple of years, so I’m sure Debian will be more than adequate.