Summary
Filing here because issues are disabled on falcondev-oss/github-actions-runner, and this is where the setup is documented.
CUSTOM_ACTIONS_RESULTS_URL is silently ignored by the published runner releases. The source at the release tag contains the patch, but the built artifact does not, so the override never takes effect and actions/cache continues talking to GitHub.
Verified across the three most recent releases (2.337.0, 2.336.0, 2.335.1), on linux-arm64.
Evidence
Source at the tag has it:
$ gh api repos/falcondev-oss/github-actions-runner/contents/src/Runner.Worker/Handlers/NodeScriptActionHandler.cs?ref=v2.337.0 \
-q '.content' | base64 -d | grep -c CUSTOM_ACTIONS_RESULTS_URL
1
The published release asset does not:
$ curl -sL -o r.tar.gz https://github.com/falcondev-oss/github-actions-runner/releases/download/v2.337.0/actions-runner-linux-arm64-2.337.0.tar.gz
$ tar xzf r.tar.gz bin/Runner.Worker.dll
$ grep -ac CUSTOM_ACTIONS_RESULTS_URL bin/Runner.Worker.dll
0
Same result for v2.336.0 and v2.335.1.
The container image inherits this, because images/Dockerfile installs that tarball:
curl -f -L -o runner.tar.gz https://github.com/falcondev-oss/github-actions-runner/releases/download/v${RUNNER_VERSION}/actions-runner-${TARGETOS}-${RUNNER_ARCH}-${RUNNER_VERSION}.tar.gz
Confirmed inside a running container from ghcr.io/falcondev-oss/actions-runner:2.337.0 (digest sha256:32a63e96…, which :latest also points at):
$ grep -ac CUSTOM_ACTIONS_RESULTS_URL /home/runner/bin/Runner.Worker.dll
0
How it presents
Everything looks correct, which is what makes it costly to diagnose:
- the variable is set and readable in the runner container (
printenv CUSTOM_ACTIONS_RESULTS_URL returns the URL)
- the runner registers fine and reports
Current runner version: '2.337.0'
- jobs run normally and succeed
- the cache server receives zero requests — not an auth failure, not a 4xx, nothing
actions/cache uploads to GitHub as though the override were never set
There is no warning anywhere that the variable was ignored. On a slow uplink the only symptom is that the cache step stays slow, which reads as "the cache server is misconfigured" rather than "the runner has no such feature".
Environment
ghcr.io/falcondev-oss/actions-runner:2.337.0 / :latest, linux/arm64
- Actions Runner Controller v2 scale sets (gha-runner-scale-set 0.13.1)
- cache server 9.7.0
actions/cache v4.3.0 (v2/Twirp cache API)
Suggested checks
The release workflow appears to build from something other than the tagged source, or to package a prebuilt upstream layout over the compiled output. A cheap regression guard would be to grep the built Runner.Worker.dll for CUSTOM_ACTIONS_RESULTS_URL in CI before publishing — the patch is the fork's entire reason to exist, so its absence should fail the release.
It would also help if the runner logged a line when the override is applied. A one-line "using custom results URL: …" at startup turns a silent no-op into something a user can see immediately.
Impact on the documented setup
The getting-started guide points users at ghcr.io/falcondev-oss/actions-runner plus CUSTOM_ACTIONS_RESULTS_URL. With the current published images that combination is a no-op, so a cache server deployed by following the docs receives nothing and every user reaches the same dead end.
Summary
Filing here because issues are disabled on
falcondev-oss/github-actions-runner, and this is where the setup is documented.CUSTOM_ACTIONS_RESULTS_URLis silently ignored by the published runner releases. The source at the release tag contains the patch, but the built artifact does not, so the override never takes effect andactions/cachecontinues talking to GitHub.Verified across the three most recent releases (2.337.0, 2.336.0, 2.335.1), on
linux-arm64.Evidence
Source at the tag has it:
The published release asset does not:
Same result for
v2.336.0andv2.335.1.The container image inherits this, because
images/Dockerfileinstalls that tarball:Confirmed inside a running container from
ghcr.io/falcondev-oss/actions-runner:2.337.0(digestsha256:32a63e96…, which:latestalso points at):How it presents
Everything looks correct, which is what makes it costly to diagnose:
printenv CUSTOM_ACTIONS_RESULTS_URLreturns the URL)Current runner version: '2.337.0'actions/cacheuploads to GitHub as though the override were never setThere is no warning anywhere that the variable was ignored. On a slow uplink the only symptom is that the cache step stays slow, which reads as "the cache server is misconfigured" rather than "the runner has no such feature".
Environment
ghcr.io/falcondev-oss/actions-runner:2.337.0/:latest, linux/arm64actions/cachev4.3.0 (v2/Twirp cache API)Suggested checks
The release workflow appears to build from something other than the tagged source, or to package a prebuilt upstream layout over the compiled output. A cheap regression guard would be to grep the built
Runner.Worker.dllforCUSTOM_ACTIONS_RESULTS_URLin CI before publishing — the patch is the fork's entire reason to exist, so its absence should fail the release.It would also help if the runner logged a line when the override is applied. A one-line "using custom results URL: …" at startup turns a silent no-op into something a user can see immediately.
Impact on the documented setup
The getting-started guide points users at
ghcr.io/falcondev-oss/actions-runnerplusCUSTOM_ACTIONS_RESULTS_URL. With the current published images that combination is a no-op, so a cache server deployed by following the docs receives nothing and every user reaches the same dead end.