Your GitLab Executor Now Tells You When It's Behind
If you run GetMac runners on GitLab CI, you install a small binary — getmac-gitlab-executor — on your runner host. Until now, nothing told you when a new version shipped. You found out by reading a changelog, or by hitting a bug we'd already fixed.
Starting with v0.2.0, the executor checks for newer releases and says so in your job log:
WARN A newer version of getmac-gitlab-executor is available current=0.1.0 latest=0.2.0 upgrade=https://github.com/getmac-io/getmac-gitlab-executor/releases/latest
That's the whole feature. It tells you. It does not act.
Why It Doesn't Update Itself
The obvious version of this feature downloads the new binary and swaps it in. We built that first, then deliberately threw it away.
The executor isn't a long-running service. GitLab Runner invokes it once per job stage — config, then prepare, then run, then cleanup — as four separate processes. A binary that replaces itself during config means the rest of that job runs on a version different from the one that started it. Your prepare and your cleanup would be different software.
The second reason matters more. Self-updating means every runner you own executes code it downloaded, unattended, at the moment a job happened to start. That turns a routine Tuesday release of ours into an immediate change on your infrastructure, with no window in which you could have said no.
We'd rather you ran a version you chose. So the executor reports, and upgrading stays a deliberate act — a decision you make, at a time you pick, on a version you've read the notes for.
It Can't Break Your Build
A check that runs on every job has to be incapable of causing damage. This one is built so that the worst case is silence:
- It can't fail a job. Every error path ends quietly. GitHub down, rate-limited, DNS broken, no network at all — the executor shrugs and carries on.
- It can't stall a job. The request is bounded by a three-second timeout.
- It can't spam GitHub. We query at most once every 24 hours and cache the answer, so the warning still appears in every job log without an API call on every job.
- It writes to stderr only. The
configstage's stdout is JSON that GitLab Runner parses; the warning never goes near it.
If you'd rather not have it at all, add one flag to config_args in your config.toml:
config_args = ["config", "--getmac-cloud-api-key", "<API_KEY>", "--disable-update-check"]
One Thing To Do By Hand, Once
While building this we found that our release pipeline had been stamping the version number into a path that didn't exist. Go's linker ignores that silently — the build succeeds and looks perfectly normal — so every executor we've released so far reports its version as dev.
That's fixed from v0.2.0 onward. It also means the update check can't reach you retroactively: a binary that doesn't know its own version has nothing to compare, so it stays quiet. Your currently installed executor will never tell you to upgrade.
So this one upgrade is manual. After it, the executor keeps you informed on its own.
Grab the latest release here: github.com/getmac-io/getmac-gitlab-executor/releases/latest
While you're there: if your config.toml still lists variables with a CUSTOM_ENV_ prefix, drop it. GitLab Runner adds that prefix itself, so those settings were never being read.
Get Started
Nothing to configure — update checks are on by default once you're on v0.2.0.
As always, we'd love to hear your feedback — join our Discord community and tell us what else you'd like the executor to surface.
— The GetMac Team