npm publishing from CI has never worked: trusted publisher is not configured (v0.0.9 tagged but unpublished)

Current state

v0.0.9 is tagged at e353bbc and is not published. npm still serves only 0.0.6. The tag is valid and the workflow file at that commit is correct — the only missing piece is on the npm side.

Not urgent: the Docker image is the artifact currently being consumed, so this blocks the npm channel only.

Symptom

Run 30543971082 got all the way through Update npm, npm ci, npm run build, and a full green npm test, then failed on the last step:

npm error code ENEEDAUTH
npm error need auth This command requires you to be logged in to https://registry.npmjs.org/

The tarball itself built fine — 0.0.9, 136 files, 100.2 kB packed / 524.2 kB unpacked.

Root cause

publish-npm.yml depends entirely on OIDC trusted publishing. It declares permissions: id-token: write, but:

• it sets no NODE_AUTH_TOKEN, and actions/setup-node@v4 is configured without registry-url, so no .npmrc is ever written — there is no token fallback;
• the repository has no npm credential of any kind (gh secret list returns only GCP_SA_KEY).

So the publish can only succeed if npm accepts the OIDC token via a trusted publisher configured on the package. That configuration does not exist, hence ENEEDAUTH.

This has never worked

Worth recording explicitly, because the workflow's presence implies otherwise:

• 0.0.6 was published at 2026-04-27T22:48:59.899Z by npm user o1-labs <npm@o1labs.org>, and the package's created timestamp is the same instant.
• No CI run exists at that time. The nearest successful Publish Package run was 20344320453 on 2025-12-18, four months earlier, from a workflow_dispatch on branch leon/fix-release-workflow.
• Every tag-triggered publish run in this repo's history has failed: v0.0.6 (25001081251), v0.0.9 first attempt (30540591005, a separate Node-engine bug fixed in #207), and v0.0.9 second attempt (30543971082, this issue).

0.0.6 was published by hand. The OIDC path in publish-npm.yml has never once succeeded end to end, so --provenance has never actually been exercised.

Fix (requires @o1-labs npm org owner/admin)

On npmjs.com → @o1-labs/mina-archive-node-graphql → Settings → Trusted Publisher → GitHub Actions:

Field	Value
Organization or user	o1-labs
Repository	Archive-Node-API
Workflow filename	publish-npm.yml
Environment	(leave blank)

The environment field must stay empty: jobs.publish declares no environment:, so a non-empty value on npm's side produces an OIDC claim mismatch and the same failure. The workflow filename must be the bare basename, not a path.

Once saved, gh run rerun --failed 30543971082 completes the v0.0.9 release — no re-tagging needed, since v0.0.9 already points at e353bbc and that commit's workflow file is correct.

Alternative, if trusted publishing is not wanted

Add an npm automation or granular-write token as repo secret NPM_TOKEN, then patch the workflow:

- uses: actions/setup-node@v4
  with:
    node-version: '20'
    registry-url: 'https://registry.npmjs.org'
...
- run: npm publish --provenance --access public
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

This introduces a long-lived credential to rotate, which is why trusted publishing is preferable. It would also require moving the v0.0.9 tag again, since the workflow file would change.

Suggested follow-up

Whichever path is taken, the first successful run should be treated as the real test of this workflow — it will be the first time the publish step has ever passed. Worth confirming afterwards that the provenance attestation on the published 0.0.9 points at e353bbc.

Start with publish-npm.yml and the failed GitHub Actions run 30543971082; review the publish step and its OIDC authentication setup. Check the npm package's trusted publisher configuration against the repository and workflow details, then rerun the failed job. Done means v0.0.9 is published successfully with provenance pointing to e353bbc.