Build-time cross-repo Go module fetch fails: can't authenticate to mathias/cad (private) #14

New Issue

2026-09-05T09:37:54Z

mathias commented

2026-09-05 09:37:54 +00:00

Same failure class as agentsquad#120 (filed alongside this, full diagnosis there) -- cad-atlas's Build & Import job fails:

go: git.d-ma.be/mathias/cad@v0.10.0: reading .../go.mod at revision v0.10.0: git ls-remote ...: exit status 128:
	remote: Failed to authenticate user
	fatal: Authentication failed for 'https://git.d-ma.be/mathias/cad.git/'

Verified mathias/cad exists, not archived, v0.10.0 tag present, reachable with a different (working) token. cad-atlas's own build-time credential secret specifically cannot authenticate to it.

Fix needs a valid, correctly-scoped replacement token minted for whichever secret feeds this Dockerfile's --mount=type=secret,id=gitea_token step -- see agentsquad#120 for the full write-up and why this can't be completed from a sandboxed agent session (needs gitea-admin-mcp run locally with real admin credentials).

Same failure class as agentsquad#120 (filed alongside this, full diagnosis there) -- `cad-atlas`'s `Build & Import` job fails: ``` go: git.d-ma.be/mathias/cad@v0.10.0: reading .../go.mod at revision v0.10.0: git ls-remote ...: exit status 128: remote: Failed to authenticate user fatal: Authentication failed for 'https://git.d-ma.be/mathias/cad.git/' ``` Verified `mathias/cad` exists, not archived, `v0.10.0` tag present, reachable with a different (working) token. cad-atlas's own build-time credential secret specifically cannot authenticate to it. Fix needs a valid, correctly-scoped replacement token minted for whichever secret feeds this Dockerfile's `--mount=type=secret,id=gitea_token` step -- see agentsquad#120 for the full write-up and why this can't be completed from a sandboxed agent session (needs gitea-admin-mcp run locally with real admin credentials).

mathias commented

2026-09-05 11:12:54 +00:00

Fixed. Root cause: the DMABE_GITEA_API_TOKEN repo secret on this repo held a stale value — hence fatal: Authentication failed for 'https://git.d-ma.be/mathias/cad.git/', an invalid credential rather than an unauthorised one.

That distinction is what separated this from agentsquad#120, which failed on the same build step with Repository not found — a valid token with no access. Same symptom class, two different faults; treating them as one would have fixed neither.

Confirmed before changing anything: the current DMABE_GITEA_API_TOKEN value can git ls-remote mathias/cad and see tag v0.10.0. So the token was fine; the copy sitting in this repo's Actions secrets was not.

Fix: refreshed the DMABE_GITEA_API_TOKEN Actions secret with the current value (PUT .../actions/secrets/DMABE_GITEA_API_TOKEN → HTTP 204). The value was piped to curl over stdin rather than placed in argv, so it never entered a command line or a transcript.

Verified end to end: reran the failed job (run 5595) — Build & Import = success, Deploy via GitOps = success, Lint / Test / Vet = success.

Worth a follow-up, deliberately not done here: this repo authenticates its build with DMABE_GITEA_API_TOKEN, which is a broad operator token (write:issue, write:repository, write:user). agentsquad does the better thing — a dedicated agentsquad-bot account holding a scoped token, now with read-only collaborator access on exactly the repos it needs. Repointing cad-atlas at the same bot pattern would drop its build credential from write-everything to read-two-repos. That is a privilege improvement, not a bug fix, so it should be its own change with its own green run rather than smuggled into an outage fix.

**Fixed.** Root cause: the `DMABE_GITEA_API_TOKEN` repo secret on this repo held a **stale value** — hence `fatal: Authentication failed for 'https://git.d-ma.be/mathias/cad.git/'`, an invalid credential rather than an unauthorised one. That distinction is what separated this from agentsquad#120, which failed on the same build step with `Repository not found` — a *valid* token with no access. Same symptom class, two different faults; treating them as one would have fixed neither. Confirmed before changing anything: the current `DMABE_GITEA_API_TOKEN` value *can* `git ls-remote` `mathias/cad` and see tag `v0.10.0`. So the token was fine; the copy sitting in this repo's Actions secrets was not. **Fix:** refreshed the `DMABE_GITEA_API_TOKEN` Actions secret with the current value (`PUT .../actions/secrets/DMABE_GITEA_API_TOKEN` → HTTP 204). The value was piped to curl over stdin rather than placed in argv, so it never entered a command line or a transcript. **Verified end to end:** reran the failed job (run 5595) — `Build & Import` = success, `Deploy via GitOps` = success, `Lint / Test / Vet` = success. **Worth a follow-up, deliberately not done here:** this repo authenticates its build with `DMABE_GITEA_API_TOKEN`, which is a broad operator token (`write:issue, write:repository, write:user`). agentsquad does the better thing — a dedicated `agentsquad-bot` account holding a scoped token, now with read-only collaborator access on exactly the repos it needs. Repointing cad-atlas at the same bot pattern would drop its build credential from write-everything to read-two-repos. That is a privilege improvement, not a bug fix, so it should be its own change with its own green run rather than smuggled into an outage fix.

mathias closed this issue

2026-09-05 11:12:54 +00:00

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mathias/cad-atlas#14