Provision Docker git auth for private remote build contexts on fresh hosts #427

New issue

Closed

opened 2026-07-02 06:23:42 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-07-02 06:23:42 +00:00

Owner

Wanted outcome:

ansible configures whatever Docker/BuildKit auth is required so a fresh host can successfully docker build from the private Forgejo Git URL used as the build context
the solution must work non-interactively on fresh hosts, not assume a pre-warmed manual credential helper state
keep the role compatible with the existing always-on service shape

Acceptance:

a fresh host can converge the role and build the image from the private remote Git context without the auth failure that originally drove the local-clone workaround
the credential path is documented clearly enough to debug and rotate
secrets stay out of tracked files

Constraints:

prefer a real Docker/BuildKit auth fix over abandoning remote Git contexts
use the repo's existing secret/runtime conventions rather than inventing ad hoc tracked config

Context:

this is a follow-up to the local-build workaround direction discussed around infrastructure#426
the operator explicitly prefers fixing Docker Git auth instead of cloning locally and building from a stable host checkout

The always-on agent-proxy role currently avoids Docker remote Git build contexts by switching to a local checkout/build shape. That unblocks fresh hosts, but the operator preference is to keep the remote Git build-context flow and fix the underlying authentication path instead. Wanted outcome: - ansible configures whatever Docker/BuildKit auth is required so a fresh host can successfully `docker build` from the private Forgejo Git URL used as the build context - the solution must work non-interactively on fresh hosts, not assume a pre-warmed manual credential helper state - keep the role compatible with the existing always-on service shape Acceptance: - a fresh host can converge the role and build the image from the private remote Git context without the auth failure that originally drove the local-clone workaround - the credential path is documented clearly enough to debug and rotate - secrets stay out of tracked files Constraints: - prefer a real Docker/BuildKit auth fix over abandoning remote Git contexts - use the repo's existing secret/runtime conventions rather than inventing ad hoc tracked config Context: - this is a follow-up to the local-build workaround direction discussed around infrastructure#426 - the operator explicitly prefers fixing Docker Git auth instead of cloning locally and building from a stable host checkout

coilyco-ops commented

2026-07-02 06:23:51 +00:00

Owner

🔒 Reserved by ward agent --driver goose — container engineer-goose-infrastructure-427 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T06:23:49Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Goose, via ward agent

🔒 Reserved by `ward agent --driver goose` — container `engineer-goose-infrastructure-427` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T06:23:49Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Goose, via `ward agent`

coilysiren closed this issue

2026-07-02 06:40:38 +00:00

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-07-08 22:19:00 +00:00

Make agent workflow defaults configurable and default engineers to PRs #707