Probe what cache endpoint the runner exports #180

Closed

thatguygriff wants to merge 2 commits from ci/probe-cache-service into main

pull from: ci/probe-cache-service

merge into: :main

:main

Conversation 0 Commits 2 Files Changed 1

+91

thatguygriff commented 2026-08-20 18:14:05 +00:00

Owner

Copy Link

Copy Source

Diagnostic only — not for merge. Opened so the workflow runs; I will close it and delete the branch once it has answered.

actions/cache refuses to run on these runners, printing its GHES warning, on both v3 and v4 (tested in #179, run 529). Two explanations survive and they need different fixes:

1. Cache is off in act_runner's config. No ACTIONS_CACHE_URL is exported, so the runner has nothing to point a patched bundle at. Fix is cache.enabled in config.yaml on each cluster.
2. A cache is served, but the runner's bundle patcher does not recognise these bundles and leaves the GHES gate shut. That would be a runner bug worth reporting upstream.

Whether the runner exports a cache URL separates the two.

The probe needs no PHP, so it stays off the slow setup-php path and answers in seconds. Note the rest of CI will still run on this PR, since ci.yml also triggers on pull_request — ignore it.

On safety

URLs are printed as values, since they are plain endpoints. Tokens are reported as set/unset only, and the variable-listing step strips values with sed 's/=.*//', so no credential reaches the log.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

**Diagnostic only — not for merge.** Opened so the workflow runs; I will close it and delete the branch once it has answered. `actions/cache` refuses to run on these runners, printing its GHES warning, on both v3 and v4 (tested in #179, run 529). Two explanations survive and they need different fixes: 1. **Cache is off in act_runner's config.** No `ACTIONS_CACHE_URL` is exported, so the runner has nothing to point a patched bundle at. Fix is `cache.enabled` in `config.yaml` on each cluster. 2. **A cache is served, but the runner's bundle patcher does not recognise these bundles** and leaves the GHES gate shut. That would be a runner bug worth reporting upstream. Whether the runner exports a cache URL separates the two. The probe needs no PHP, so it stays off the slow setup-php path and answers in seconds. Note the rest of CI will still run on this PR, since `ci.yml` also triggers on `pull_request` — ignore it. ### On safety URLs are printed as values, since they are plain endpoints. Tokens are reported as `set`/`unset` only, and the variable-listing step strips values with `sed 's/=.*//'`, so no credential reaches the log. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff added 1 commit 2026-08-20 18:14:05 +00:00

Probe what cache endpoint the runner exports ... a26c481c8f

Diagnostic for #178, meant to be deleted once it has answered.

actions/cache refuses to run on these runners, printing its GHES warning,
on both v3 and v4. Two explanations survive and they need different fixes:
cache is off in act_runner's config, so there is no ACTIONS_CACHE_URL and
nothing for the runner's bundle patcher to aim at; or a cache is served
and the patcher does not recognise these bundles, leaving the gate shut,
which would be a runner bug to report upstream.

Whether the runner exports a cache URL separates the two. The job needs no
PHP, so it stays off the slow setup-php path and answers in seconds.

URLs are printed as values since they are plain endpoints. Tokens are
reported as set or unset only, and the second step lists variable names
without values, so no credential reaches the log.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff added 1 commit 2026-08-20 18:16:26 +00:00

Probe which actions/cache variant can reach the v2 cache service ... 3ec2440bd1

The first probe answered the original question and raised a better one.
ACTIONS_CACHE_URL is unset but ACTIONS_RESULTS_URL points at
gitea-unsupervised-git-http.gitea.svc.cluster.local:3000, so the runner
does serve a cache — the v2 service, not v1. actions/cache resolves to
v4.3.0, which can speak v2, but only when ACTIONS_CACHE_SERVICE_V2 is
set, and the runner does not set it. So the action falls back to v1,
finds no endpoint, and trips its GHES gate on the way past.

Three variants to find one that reaches the service that is already
running: v4 with the flag forced, v6.1.0 which is current, and v6 with
the flag. Any that saves is a fix that lives in this repository.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff referenced this pull request 2026-08-20 18:19:33 +00:00

CI: Setup PHP is slow and flaky for PHP 8.3 only, on arm64 runners #178

thatguygriff closed this pull request 2026-08-20 18:19:42 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

bug

Something isn't working

enhancement

Extends an existing feature

feature

New user-facing capability

payments

Billing, Stripe, receipts, reporting

security

Security vulnerability or hardening

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

Kydoimos (Kydoimos) thatguygriff (James Griffin-Allwood)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Unsupervised/unsupervised-scheduler#180