thatguygriffandClaude Opus 5
43b903c1c8
CI / Tests (PHP 8.2) (pull_request) Successful in 53s
CI / Tests (PHP 8.1) (pull_request) Successful in 1m3s
CI / No Debug Code (pull_request) Successful in 2s
CI / Coding Standards & Static Analysis (pull_request) Successful in 3m27s
CI / Tests (PHP 8.3) (pull_request) Successful in 6m47s
CI / Tests (PHP 8.5) (pull_request) Failing after 12m17s
CI / Build Plugin Zip (pull_request) Skipped
Tested and the hypothesis is dead. actions/cache@v4 resolved properly (SHA 0057852) and printed the same GHES warning as v3, so the action version was not what was closing the gate. That points at the runner rather than the action. Gitea's docs say the runner patches the GHES check out of the action's bundle only when it recognises it, and that a bundle it does not recognise "is left alone". No patching for either v3 or v4, and no ACTIONS_CACHE_URL to patch it towards, is what you get when cache is simply off in the runner config. So the fix is cache.enabled in act_runner's config.yaml, with host set to an address job containers can reach. Nothing in this repository unblocks it, and inert steps are what let the Composer cache rot unnoticed, so the experiment comes out again. Both halves — the apt cache and the move to v4 — should land together once the runner serves a cache. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks