Retry image builds once after a GHCR 429 #17

2026-10-15T20:05:06-07:00

dejima-agent commented

2026-10-15 20:05:06 -07:00

Summary generated by LLM agent

The streamer build fails intermittently with 429 Too Many Requests from ghcr.io while pulling its base image ghcr.io/linuxserver/baseimage-selkies. It happens both on the GitHub mirror and on the forge's own runners.

On GitHub the run history shows the pattern:

in the last two runs, the streamer job failed on its first attempt, 13 to 26 seconds in;
re-running it a few minutes later succeeded both times;
the app and session-manager jobs, whose base images don't come from GHCR, never failed.

Because it also happens on a single home runner, the limit is on GHCR's side for this image, not on our requests. Signing in to ghcr.io doesn't avoid it.

In both workflows, the build step now has continue-on-error. If it fails, the job waits two minutes and runs the same build once more, and the job fails only if the retry fails too. This uses no third-party actions, and the two workflows' build steps are identical.

Testing: prettier passes and the YAML parses. The retry path only runs on a real 429, so it won't be exercised until one happens.

A possible follow-up is pulling the base image from a registry other than GHCR. LinuxServer also publishes it to Quay (quay.io/linuxserver.io/baseimage-selkies) and Docker Hub (lsiobase/selkies), but I couldn't confirm those tags or the runner's network access from the sandbox.

**Summary generated by LLM agent** The streamer build fails intermittently with `429 Too Many Requests` from ghcr.io while pulling its base image `ghcr.io/linuxserver/baseimage-selkies`. It happens both on the GitHub mirror and on the forge's own runners. On GitHub the run history shows the pattern: - in the last two runs, the streamer job failed on its first attempt, 13 to 26 seconds in; - re-running it a few minutes later succeeded both times; - the app and session-manager jobs, whose base images don't come from GHCR, never failed. Because it also happens on a single home runner, the limit is on GHCR's side for this image, not on our requests. Signing in to ghcr.io doesn't avoid it. In both workflows, the build step now has `continue-on-error`. If it fails, the job waits two minutes and runs the same build once more, and the job fails only if the retry fails too. This uses no third-party actions, and the two workflows' build steps are identical. Testing: prettier passes and the YAML parses. The retry path only runs on a real 429, so it won't be exercised until one happens. A possible follow-up is pulling the base image from a registry other than GHCR. LinuxServer also publishes it to Quay (`quay.io/linuxserver.io/baseimage-selkies`) and Docker Hub (`lsiobase/selkies`), but I couldn't confirm those tags or the runner's network access from the sandbox.

dejima-agent added 1 commit 2026-10-15 20:05:07 -07:00

ci: retry GitHub image builds once after a GHCR 429 d54a44da1d

The streamer's base image pull from ghcr.io intermittently gets 429 Too
Many Requests on GitHub's shared runners, failing the first attempt of
the last two runs; re-running minutes later succeeded both times.

dejima-agent added 1 commit 2026-10-15 21:28:06 -07:00

ci: retry forge image builds once after a GHCR 429 too d45aa8b603

dejima-agent changed title from ~~Retry GitHub image builds once after a GHCR 429~~ to Retry image builds once after a GHCR 429

2026-10-15 21:28:12 -07:00

branderson approved these changes 2026-10-15 21:29:21 -07:00

branderson merged commit a84ba7f6de into main

2026-10-15 21:29:33 -07:00

dejima-agent referenced this pull request

2026-10-16 00:02:13 -07:00

Stop building images on the GitHub mirror #18

Sign in to join this conversation.