Gitea runner v1.0.0 asset rename breaks GARM tools discovery

[igrikus]

Summary

Gitea runner v1.0.0 renamed release assets from the previous act_runner-* naming scheme to gitea-runner-*. This breaks GARM's Gitea tools discovery because GARM parses the OS/architecture from the asset filename and currently rejects the new names.

As a result, GARM cannot populate the runner tools cache for linux/amd64, and runner provisioning fails before the VM/userdata can start.

Impact

All Gitea-backed pools using linux/amd64 runners fail to create new runners.

Example provider error:

failed to get runner spec: failed to get tools: failed to find tools for OS linux and arch amd64

Example GARM logs:

ignoring unrecognized tools arch tool=gitea-runner-1.0.0-linux-amd64
ignoring unrecognized tools arch tool=gitea-runner-1.0.0-linux-arm64

Expected Behavior

GARM should recognize Gitea runner v1.0.0 assets and populate tools metadata for supported OS/architecture combinations, especially:

Actual Behavior

GARM ignores the new release assets as unrecognized, then runner creation fails because no matching tool exists in the cache.

Suggested Fix

Support both Gitea runner asset naming formats:

act_runner-<version>-<os>-<arch>
gitea-runner-<version>-<os>-<arch>

Possibly also make parsing less dependent on the binary prefix and instead parse from the right side of the filename.

Additional Note (my current workaround)

I was forced to use the Use Internal Tools Metadata option in the Endpoint + pre-bake the runner binary inside the VM image (GCP provider; not sure about the ability to do this with other providers).

That way, GARM starts the VM successfully, then sees that the runner binary is already present and ignores the hardcoded Internal Tools URL.

However, this issue still affects the default external metadata flow against the official Gitea runner releases API.

[gabriel-samfira]

• insert cat hissing at monitor gif *

will take a look. At first glance, they seem to no longer be using semver notation. We kind of relied on that to determine if we can support the version of act runner. But at this point it's safe if we skip checking. Will try to fix soon.

[gabriel-samfira]

In the meantime, you might get a working setup if you select Use Internal Tools Metadata in the edit endpoint dialogue of your gitea endpoint.

Or via CLI:

garm-cli gitea endpoint update --use-internal-tools-metadata YourGiteaEndpoint

The nightly act_runner downloads are still there.

I will push an update tonight.

[gabriel-samfira]

I proposed a branch here:

• Fix Gitea tools parser #733

Once tests pass, I will merge it and kick off a manual build of the container image. Would you mind testing it and reporting back? If all is well for you, I'll cut a new bugfix release (was not expecting to have to do a release so soon).

[igrikus]

Sure thing, happy to test it

[gabriel-samfira]

nightly image was built with the patch. Give it a shot. Let me know if it works for you.

[igrikus]

I tested the nightly image with the patch. The original tools discovery issue looks fixed now: GARM can create and configure the runner!

However, I found a new problem 🙂

The runner is registered successfully, but it stays Idle and never picks up the job

The runner events show:

using cached runner found in /home/runner/act-runner
configuring runner
runner registration token was retrieved
runner successfully configured after 1 attempt(s)
starting service
generating systemd unit file
runner successfully installed

I checked the VM before GARM deleted it, and the actual runner service was failing:

actions.runner.org.service: Failed to locate executable /home/runner/gitea-runner/gitea-runner: No such file or directory
actions.runner.org.service: Failed at step EXEC spawning /home/runner/gitea-runner/gitea-runner: No such file or directory
actions.runner.org.service: Main process exited, code=exited, status=203/EXEC

After checking the running GARM instance, I think the root cause is a mismatch between the stored system install template and the generated systemd unit

My pool uses the default system template:

Template: gitea_linux (ID: 3)

But that template in the live GARM DB is still the old pre-fix version. It still contains:

RUN_HOME="/home/{{.RunnerUsername}}/act-runner"
./act_runner register ...
getRunnerFile "systemd/unit-file?runAsUser={{ .RunnerUsername }}" "$SVC_NAME"

At the same time, the patched GARM now generates a new-style Gitea systemd unit:

ExecStart=/home/runner/gitea-runner/gitea-runner daemon --once
WorkingDirectory=/home/runner/gitea-runner

It looks like existing system templates are not automatically updated when upgrading the GARM container?

I assume this should fix my installation:

garm-cli template restore --forge-type gitea --os-type linux

Could you confirm whether restoring system templates manually is the expected migration step after this change, or should GARM migrate/update the existing system templates automatically?

Also, for custom pre-baked images like mine, I assume the cached runner path now needs to change from:

/home/runner/act-runner/act_runner

to:

/home/runner/gitea-runner/gitea-runner

[gabriel-samfira]

Can you run:

garm-cli template restore

and then:

garm-cli pool runner rotate --yes-i-really-mean-it <POOL ID GOES HERE>

and see if that fixes it?

[gabriel-samfira]

The template was updated in the code, but it won't be migrated to the database unless a restore is triggered, because the one in the DB is editable by the user. So it needs to be an explicit action.

[igrikus]

yes, that worked (template restore was enough in my case)

I think this should be reflected in release notes?

[gabriel-samfira]

It will be. The goal is to make sure things work first. I will cut a release today.

[gabriel-samfira]

published a new release:

https://github.com/cloudbase/garm/releases/tag/v0.2.1

Image building as we speak.