deploy: agent-tools wait step discards skopeo errors, masking the real failure #224

New issue

Closed

opened 2026-07-25 09:17:18 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-07-25 09:17:18 +02:00

Owner

The 'Wait for the agent-tools refs' step in .forgejo/workflows/deploy.yml runs skopeo inspect --no-tags ... >/dev/null 2>&1, so when the probe fails the log only ever shows 'waiting for …' and, at the 30-minute deadline, the generic 'still does not resolve' error.

This step has never passed since it was introduced with #221: deploy runs 294 and 296 (both attempts) all failed at exactly the deadline — including a re-run whose entire window was after the agent-tools tags were published and verified anonymously pullable (the publish job's own scratch-storage anonymous pull-back passed at 2026-07-25 02:43, and the same token→manifest→blob sequence returns 200 from the deploy target host). So skopeo is failing in the runner environment for some reason unrelated to tag existence — TLS trust, network path from the job container, whatever — and the redirect to /dev/null hides it.

Surface skopeo's stderr on every retry and in the deadline error so the next main merge diagnoses itself.

The 'Wait for the agent-tools refs' step in .forgejo/workflows/deploy.yml runs `skopeo inspect --no-tags ... >/dev/null 2>&1`, so when the probe fails the log only ever shows 'waiting for <ref> …' and, at the 30-minute deadline, the generic 'still does not resolve' error. This step has never passed since it was introduced with #221: deploy runs 294 and 296 (both attempts) all failed at exactly the deadline — including a re-run whose entire window was *after* the agent-tools tags were published and verified anonymously pullable (the publish job's own scratch-storage anonymous pull-back passed at 2026-07-25 02:43, and the same token→manifest→blob sequence returns 200 from the deploy target host). So skopeo is failing in the runner environment for some reason unrelated to tag existence — TLS trust, network path from the job container, whatever — and the redirect to /dev/null hides it. Surface skopeo's stderr on every retry and in the deadline error so the next main merge diagnoses itself.

dominik.polakovics referenced this issue from a commit

2026-07-25 09:20:18 +02:00

fix(ci): surface skopeo's stderr in the deploy wait step (issue #224)

dominik.polakovics referenced this issue from a pull request that will close it,

2026-07-25 09:20:30 +02:00

deploy: surface skopeo's stderr in the agent-tools wait step #225

dominik.polakovics closed this issue

2026-07-25 09:29:37 +02:00

dominik.polakovics referenced this issue

2026-07-25 09:40:17 +02:00

deploy: wait step builds nixpkgs#skopeo with multiple outputs — $skopeo path is two lines, exec always fails #226

dominik.polakovics referenced this issue