Unsupervised/unsupervised-scheduler
2
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 19 Wiki Activity

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
Conversation 0 Commits 2 Files Changed 1
+91
2 Commits
Author SHA1 Message Date
thatguygriffandClaude Opus 5 3ec2440bd1 Probe which actions/cache variant can reach the v2 cache service
CI / Tests (PHP 8.1) (pull_request) Successful in 1m1s
Details
CI / No Debug Code (pull_request) Successful in 2s
Details
Cache Service Probe / Cache Service Probe (pull_request) Successful in 2s
Details
Cache Service Probe / cache@v6 (pull_request) Successful in 3s
Details
Cache Service Probe / cache@v4 + ACTIONS_CACHE_SERVICE_V2 (pull_request) Successful in 59s
Details
Cache Service Probe / cache@v6 + ACTIONS_CACHE_SERVICE_V2 (pull_request) Successful in 1m7s
Details
CI / Tests (PHP 8.2) (pull_request) Successful in 1m1s
Details
CI / Coding Standards (pull_request) Successful in 4m47s
Details
CI / Tests (PHP 8.3) (pull_request) Successful in 2m58s
Details
CI / PHPStan (pull_request) Failing after 12m12s
Details
CI / Build Plugin Zip (pull_request) Skipped
Details 
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
 2026-08-20 15:16:25 -03:00
thatguygriffandClaude Opus 5 a26c481c8f Probe what cache endpoint the runner exports
Cache Service Probe / Cache Service Probe (pull_request) Successful in 2s
Details
CI / Tests (PHP 8.1) (pull_request) Successful in 57s
Details
CI / Tests (PHP 8.2) (pull_request) Successful in 1m2s
Details
CI / No Debug Code (pull_request) Successful in 2s
Details
CI / Tests (PHP 8.3) (pull_request) Successful in 5m1s
Details
CI / Coding Standards (pull_request) Successful in 7m57s
Details
CI / Build Plugin Zip (pull_request) Skipped
Details
CI / PHPStan (pull_request) Successful in 3m4s
Details 
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
 2026-08-20 15:13:47 -03:00