You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
Current state
v0.0.9is tagged ate353bbcand is not published. npm still serves only0.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 greennpm test, then failed on the last step:The tarball itself built fine —
0.0.9, 136 files, 100.2 kB packed / 524.2 kB unpacked.Root cause
publish-npm.ymldepends entirely on OIDC trusted publishing. It declarespermissions: id-token: write, but:NODE_AUTH_TOKEN, andactions/setup-node@v4is configured withoutregistry-url, so no.npmrcis ever written — there is no token fallback;gh secret listreturns onlyGCP_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.6was published at2026-04-27T22:48:59.899Zby npm usero1-labs <npm@o1labs.org>, and the package'screatedtimestamp is the same instant.Publish Packagerun was20344320453on 2025-12-18, four months earlier, from aworkflow_dispatchon branchleon/fix-release-workflow.v0.0.6(25001081251),v0.0.9first attempt (30540591005, a separate Node-engine bug fixed in ci(publish): pin npm to 11.x so the publish job works on Node 20 #207), andv0.0.9second attempt (30543971082, this issue).0.0.6was published by hand. The OIDC path inpublish-npm.ymlhas never once succeeded end to end, so--provenancehas 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:o1-labsArchive-Node-APIpublish-npm.ymlThe environment field must stay empty:
jobs.publishdeclares noenvironment:, 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 30543971082completes thev0.0.9release — no re-tagging needed, sincev0.0.9already points ate353bbcand 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:This introduces a long-lived credential to rotate, which is why trusted publishing is preferable. It would also require moving the
v0.0.9tag 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.9points ate353bbc.