thatguygriffandClaude Opus 5
d5eb2764a3
CI / Tests (PHP 8.1) (pull_request) Successful in 55s
CI / No Debug Code (pull_request) Successful in 2s
CI / Coding Standards & Static Analysis (pull_request) Successful in 3m15s
CI / Tests (PHP 8.3) (pull_request) Successful in 4m4s
CI / Tests (PHP 8.2) (pull_request) Successful in 1m5s
CI / Tests (PHP 8.5) (pull_request) Failing after 12m14s
CI / Build Plugin Zip (pull_request) Skipped
My last conclusion was wrong. The GHES warning is not evidence that the runner has no cache server; it is actions/cache v3 disabling itself. v3's isGhes() reads GITHUB_SERVER_URL, and anything that is not github.com reads as GitHub Enterprise, so on Gitea it always trips and the action returns before touching the cache. That explains the 0.2s save perfectly well without any runner setting being off. Gitea's runner 3.0.0 release notes say every runner starts its own cache server and that the runner "patches action bundles at load time to open the GHES gate and read the cache endpoint from ACTIONS_CACHE_URL", with actions/cache supported unforked. Our runners report v3.0.0, so the server should be there and the gate should be open — but the patching evidently does not reach a v3 bundle. So this reapplies the apt cache and moves every actions/cache to v4. If the hypothesis holds the GHES warning disappears, the save step actually takes time, and a second run restores the .debs. The Composer cache gets the bump too, since it has been silently doing nothing for the same reason. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks