feat(deploy): carry the registry credential in the deployment payload #514

Merged

gmackie merged 1 commit from feat/deploy-registry-credential into main

2026-08-28 01:10:51 +00:00

gmackie commented

2026-08-28 00:58:47 +00:00

Owner

Removes the hand-set node config that #513 depends on.

#513 made the registry build able to authenticate, but the credential's only source was FG_NPM_TOKEN written by hand into /etc/forgegraph/agent.env on hetzner-fg. That is invisible, unreproducible, and silently absent on every other node — the next node to build the registry would fail exactly as this one did, with no indication why.

CI already solved this. fetchQueuedCIJobs attaches a resolved registry config per repository via resolveCIRegistryForRepository. Deployments resolve the same repositoryId a few lines earlier in the poll route, so this reuses the same helper and carries the result in the payload.

poll route — resolve the registry alongside the repository lookup already happening, attach as registry
client — PendingDeployment.Registry, matching the field CIJob already has
agent — buildEnv exports FG_NPM_TOKEN for nix build, mirroring how gitauth supplies git credentials. Environment rather than argv for the same stated reason: argv is world-readable through /proc.

Absent a configured registry the token is empty and buildEnv returns nil, so nix inherits the parent environment exactly as before — public flakes are untouched.

Tests — 4 new Go tests on the env assembly: the token is carried, the parent environment is preserved when materialised, a git credential and an npm token coexist (the case that would break if either clobbered the other), and an empty token is never exported. go build/vet clean, existing internal/deploy and cmd/agent suites pass, turbo run typecheck 7/7, poll-route tests 9/9.

Ships with the next agent release. Once it is out, the hand-set FG_NPM_TOKEN in /etc/forgegraph/agent.env can be removed — I have left it in place so the registry keeps deploying in the meantime.

🤖 Generated with Claude Code

Removes the hand-set node config that #513 depends on. #513 made the registry build able to authenticate, but the credential's only source was `FG_NPM_TOKEN` written by hand into `/etc/forgegraph/agent.env` on hetzner-fg. That is invisible, unreproducible, and silently absent on every other node — the next node to build the registry would fail exactly as this one did, with no indication why. **CI already solved this.** `fetchQueuedCIJobs` attaches a resolved registry config per repository via `resolveCIRegistryForRepository`. Deployments resolve the same `repositoryId` a few lines earlier in the poll route, so this reuses the same helper and carries the result in the payload. - **poll route** — resolve the registry alongside the repository lookup already happening, attach as `registry` - **client** — `PendingDeployment.Registry`, matching the field `CIJob` already has - **agent** — `buildEnv` exports `FG_NPM_TOKEN` for `nix build`, mirroring how `gitauth` supplies git credentials. Environment rather than argv for the same stated reason: argv is world-readable through `/proc`. Absent a configured registry the token is empty and `buildEnv` returns nil, so nix inherits the parent environment exactly as before — public flakes are untouched. **Tests** — 4 new Go tests on the env assembly: the token is carried, the parent environment is preserved when materialised, a git credential and an npm token coexist (the case that would break if either clobbered the other), and an empty token is never exported. `go build`/`vet` clean, existing `internal/deploy` and `cmd/agent` suites pass, `turbo run typecheck` 7/7, poll-route tests 9/9. Ships with the next agent release. Once it is out, the hand-set `FG_NPM_TOKEN` in `/etc/forgegraph/agent.env` can be removed — I have left it in place so the registry keeps deploying in the meantime. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

gmackie added 1 commit

2026-08-28 00:58:47 +00:00

feat(deploy): carry the registry credential in the deployment payload

CI / gitleaks (pull_request) Successful in 6s

Details

CI / storybook (pull_request) Successful in 1m27s

Details

forgegraph/ci CI passed

CI / ci (pull_request) Successful in 9m33s

Details

c4f7244db8

The registry's nix build needs npm auth, and until now the only way it had
one was FG_NPM_TOKEN hand-set in /etc/forgegraph/agent.env on a single node.
That is invisible, unreproducible, and silently absent on every other node.

CI jobs already solve this: fetchQueuedCIJobs attaches a resolved registry
config per repository. Deployments resolve the same repositoryId a few lines
earlier, so this reuses resolveCIRegistryForRepository and the agent turns it
into FG_NPM_TOKEN for the nix build, the way gitauth already supplies git
credentials.

gmackie merged commit 250e883076 into main

2026-08-28 01:10:51 +00:00

gmackie referenced this pull request from a commit

2026-08-28 01:10:51 +00:00

Merge pull request 'feat(deploy): carry the registry credential in the deployment payload' (#514) from feat/deploy-registry-credential into main

gmackie referenced this pull request

2026-08-28 10:53:11 +00:00

chore(release): agent 0.1.63 — registry credential travels with the deployment #515

gmackie referenced this pull request

2026-08-28 10:55:11 +00:00

fix(agent): give the Workers deploy path its registry credential #516

gmackie referenced this pull request