ci(deploy): give the deploy pipelines the registry token too #499

Merged
gmackie merged 2 commits from ci/deploy-registry-token into main 2026-08-27 21:01:19 +00:00
Owner

Moved out of #340, unchanged and with its original authorship.

The change is right: deploy.yml and deploy-staging.yml wipe node_modules before installing, so every run is a cold install and @preflight/* always has to be fetched from npm.forgegraf.com — which answers 401 unauthenticated. Without a token those pipelines break the moment #340 lands.

Why it could not stay in #340. Touching a deploy workflow inside a feature PR makes Forgejo create runs for it against that PR — for both push and pull_request, even though neither file declares a pull_request trigger. They fail instantly (Failing after 0s) because they cannot be scheduled for that event.

Measured on the two commits:

commit touches deploy workflows statuses overall
2949590e no 4 success
4facdfd6 yes 8 (4 instant-fail) failure

Since green is what merges here, #340 could never have landed with it attached. On main the push: [main] trigger is coherent and the runs make sense.

No content changes from the original commit.

Moved out of #340, unchanged and with its original authorship. The change is right: `deploy.yml` and `deploy-staging.yml` wipe `node_modules` before installing, so every run is a cold install and `@preflight/*` always has to be fetched from `npm.forgegraf.com` — which answers **401** unauthenticated. Without a token those pipelines break the moment #340 lands. **Why it could not stay in #340.** Touching a deploy workflow inside a feature PR makes Forgejo create runs for it against that PR — for both `push` and `pull_request`, even though neither file declares a `pull_request` trigger. They fail instantly (`Failing after 0s`) because they cannot be scheduled for that event. Measured on the two commits: | commit | touches deploy workflows | statuses | overall | |---|---|---|---| | `2949590e` | no | 4 | **success** | | `4facdfd6` | yes | 8 (4 instant-fail) | failure | Since green is what merges here, #340 could never have landed with it attached. On `main` the `push: [main]` trigger is coherent and the runs make sense. No content changes from the original commit.
ci(deploy): give the deploy pipelines the registry token too
Some checks failed
deploy-staging.yml / ci(deploy): give the deploy pipelines the registry token too (push) Failing after 0s
deploy.yml / ci(deploy): give the deploy pipelines the registry token too (push) Failing after 0s
deploy-staging.yml / ci(deploy): give the deploy pipelines the registry token too (pull_request) Failing after 0s
deploy.yml / ci(deploy): give the deploy pipelines the registry token too (pull_request) Failing after 0s
CI / gitleaks (pull_request) Successful in 8s
CI / storybook (pull_request) Successful in 1m59s
CI / ci (pull_request) Has been cancelled
96a9b40a94
This PR adds `@preflight/runreport` from npm.forgegraf.com, which answers 401
unauthenticated:

    curl -A "npm/10" https://npm.forgegraf.com/@preflight%2Frunreport
    HTTP 401  {"error":"Missing or invalid Authorization header"}

`ci.yml` was wired for that correctly. `deploy.yml` (production, two install
steps) and `deploy-staging.yml` were not — they ran a bare `pnpm install
--frozen-lockfile`. Both wipe node_modules first, so every run is a cold
install and the fetch always happens; the first deploy after this merged would
have 401'd.

They also cannot fall back on ambient credentials: no `.npmrc` on
hetzner-worker, hetzner-fg or hetzner-master holds a token, and the repo's own
field report (2026-08-27-self-hosted-runner-cold-cache-blocks-prs.md) documents
that these runners report "pnpm cache is not found" on every job.

Applies the same block ci.yml uses, to all three install sites. Verified: each
`pnpm install` is now preceded by an auth block and its step declares
FG_REGISTRY_TOKEN (2/2 in deploy.yml, 1/1 in deploy-staging.yml), and both
files still parse as YAML.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ci(deploy): merge the duplicate env blocks, and check workflows parse
All checks were successful
CI / gitleaks (pull_request) Successful in 7s
CI / storybook (pull_request) Successful in 2m15s
forgegraph/ci CI passed
CI / ci (pull_request) Successful in 9m31s
86a59a7359
The first cut of this branch added `env:` before `run:` in a step that
already had an `env:` after it. Forgejo parses workflows with Go's
yaml.v3, which rejects duplicate mapping keys, so both deploy files
failed with:

    Unable to parse supported events in workflow: yaml: unmarshal errors:
      line 39: mapping key "env" already defined at line 19

That failure is quiet in the worst way. The run records a
preExecutionError with zero steps and 0s duration -- no log to read. And
because Forgejo cannot read `on:` either, it cannot tell the trigger does
not match: deploy-staging.yml is workflow_dispatch-only and still posted
a failing status onto this PR. Had it merged, deploy.yml would have been
unparseable and pushes to main would have stopped deploying, with nothing
obviously red to explain why.

Fix is to merge each pair into one env block.

scripts/test-workflow-yaml.mjs parses every .forgejo/workflows/*.yml the
way the runner does and asserts an `on:` block and at least one job.
Verified by reverting the fix: it fails on both files at lines 39 and
181, the same lines Forgejo reported. It also canaries its own parser
against a known-duplicate document first and exits 1 if that is accepted,
so it cannot silently degrade into a check that always passes.

Uses yaml@2.9.0, already a declared dependency of @forgegraph/api, so the
lockfile is untouched.
Author
Owner

Preview environment is live: https://pr-499-forgegraph.forgegraf.com

Deployed 86a59a73 with the beta stage's environment. It redeploys on every push and is destroyed when this PR closes.

Preview environment is live: https://pr-499-forgegraph.forgegraf.com Deployed `86a59a73` with the beta stage's environment. It redeploys on every push and is destroyed when this PR closes.
gmackie deleted branch ci/deploy-registry-token 2026-08-27 21:01:19 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
gmackie/ForgeGraph!499
No description provided.