gbreed-public/gbr-games
5
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ci: stop waiting ~9 minutes on an unreachable cache #5

Merged
greg merged 2 commits from ci/no-go-cache into main 2026-10-25 15:24:23 +00:00
Conversation 2 Commits 2 Files Changed 2
+14
greg commented 2026-10-25 15:13:16 +00:00
Owner
Copy link
Copy source

Why

validate took about 10 minutes, but only about 10 seconds of that was work. In the last main run:

  • 05:13:31 start
  • 05:18:10 Failed to restore: getCacheEntry failed: connect ETIMEDOUT 172.20.0.2:39151 (~4.7 min)
  • 05:18:11–05:18:19 modules downloaded, tests run, templates validated
  • 05:22:59 Failed to save: reserveCache failed: connect ETIMEDOUT (~4.7 min)

Both runners' built-in cache servers listen on the runner container's own Docker network, which job containers can't reach.

What

  • actions/setup-go: cache: false in all three jobs. Three small modules aren't worth caching.
  • scripts/runner/config.yaml (game-test runner template): cache.enabled: false, so any cache step skips at once instead of timing out. To take effect on VM 126, copy it to /opt/gitea-game-test-runner/ and docker compose up -d --force-recreate.

No game folders change, so this PR's run only validates.

🤖 Generated with Claude Code

## Why `validate` took about 10 minutes, but only about **10 seconds** of that was work. In the last `main` run: - 05:13:31 start - 05:18:10 `Failed to restore: getCacheEntry failed: connect ETIMEDOUT 172.20.0.2:39151` (~4.7 min) - 05:18:11–05:18:19 modules downloaded, tests run, templates validated - 05:22:59 `Failed to save: reserveCache failed: connect ETIMEDOUT` (~4.7 min) Both runners' built-in cache servers listen on the runner container's own Docker network, which job containers can't reach. ## What - `actions/setup-go`: `cache: false` in all three jobs. Three small modules aren't worth caching. - `scripts/runner/config.yaml` (game-test runner template): `cache.enabled: false`, so any cache step skips at once instead of timing out. **To take effect on VM 126**, copy it to `/opt/gitea-game-test-runner/` and `docker compose up -d --force-recreate`. No game folders change, so this PR's run only validates. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
greg added 1 commit 2026-10-25 15:13:16 +00:00
ci: stop waiting ~9 minutes on an unreachable cache
Validate game templates / validate (push) Successful in 14s
Details
Validate game templates / boot-test (push) Skipped
Details
Validate game templates / publish (push) Skipped
Details
d02ed01d26 
Validate took ~10 minutes, of which ~10 seconds was work: setup-go's
cache restore and save each waited ~4.7 minutes for a connect timeout,
because the runners' built-in cache server sits on a network job
containers can't reach. Turn off setup-go caching (three small modules
aren't worth it) and the game-test runner's cache server, so any cache
step skips at once.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
git_ai_bot commented 2026-10-25 15:13:27 +00:00
Member
Copy link
Copy source

Automated AI Review

Here's some quick feedback on your PR:

LGTM

>_Automated AI Review_ Here's some quick feedback on your PR: LGTM
greg added 1 commit 2026-10-25 15:20:43 +00:00
Merge branch 'main' into ci/no-go-cache
Validate game templates / validate (push) Successful in 19s
Details
Validate game templates / boot-test (push) Skipped
Details
Validate game templates / publish (push) Skipped
Details
e8216809d4
greg merged commit 05bfc9b061 into main 2026-10-25 15:24:23 +00:00
greg deleted branch ci/no-go-cache 2026-10-25 15:24:23 +00:00
git_ai_bot commented 2026-10-25 15:24:35 +00:00
Member
Copy link
Copy source

Automated AI Review

Here's some quick feedback on your PR:

  • No TODO/ticket reference accompanies what appears to be a temporary infrastructure workaround; once the cache server becomes reachable again, both the workflow cache: false flags and the runner cache.enabled: false will silently persist and add unnecessary dependency-download time to every CI run.
  • The identical two-line comment is duplicated verbatim across three setup-go steps in the workflow; if the reasoning or the fix changes, it must be updated in three places (and a fourth in the runner config), increasing drift risk.
  • The two changes (workflow-level cache: false vs. runner-level cache.enabled: false) address different cache layers, but a short note linking them would help a future reader confirm both are intentional rather than one being a redundant leftover.
>_Automated AI Review_ Here's some quick feedback on your PR: - No TODO/ticket reference accompanies what appears to be a temporary infrastructure workaround; once the cache server becomes reachable again, both the workflow `cache: false` flags and the runner `cache.enabled: false` will silently persist and add unnecessary dependency-download time to every CI run. - The identical two-line comment is duplicated verbatim across three `setup-go` steps in the workflow; if the reasoning or the fix changes, it must be updated in three places (and a fourth in the runner config), increasing drift risk. - The two changes (workflow-level `cache: false` vs. runner-level `cache.enabled: false`) address different cache layers, but a short note linking them would help a future reader confirm both are intentional rather than one being a redundant leftover.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
gbr-bot git_ai_bot git_pipeline greg (Gregory Reed) openhands
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gbreed-public/gbr-games#5