release.yml: restore --provenance flag + add OIDC diagnostics#34
Merged
release.yml: restore --provenance flag + add OIDC diagnostics#34
Conversation
Second iteration of the publish-nodejs fix. The previous PR (#32) cleared the wrong-thing-blocking-OIDC issue (setup-node's registry-url generating an .npmrc that forced token auth), but went too far by also removing the `--provenance` flag based on docs that claim "no flags needed for trusted publishers". The v0.1.6 canary failed with: npm error code ENEEDAUTH npm error need auth This command requires you to be logged in to https://registry.npmjs.org/ ENEEDAUTH means npm CLI didn't even *try* OIDC token exchange — it just looked for a configured _authToken, found none, and gave up. Empirically, npm 11.5+ trusted publishing *does* require `--provenance` to trigger the OIDC code path, even though the official docs claim auto-detection. Fix: - Restore `npm publish --provenance --access public` - Add `--loglevel verbose` so future auth/transport errors print enough detail to diagnose without re-running with debug logging on - Add a diagnostics step that prints whether ACTIONS_ID_TOKEN_REQUEST_URL + ACTIONS_ID_TOKEN_REQUEST_TOKEN are set (these are the GHA-injected env vars that OIDC depends on; if either is missing, OIDC can't possibly work and we want to see that in the log) - Updated the long inline comment block on the publish step to capture the *combined* understanding from PR #32 + this PR: registry-url removal + --provenance restoration are BOTH required, neither alone works After this merges I'll dispatch v0.1.7 (v0.1.6 wave already shipped 4 of 5 channels; the npm slot stays empty). The diagnostic step will confirm OIDC env vars are present regardless of whether publish succeeds or fails. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What broke (again)
The v0.1.6 canary's publish-nodejs failed with a different error than v0.1.5:
Progress vs. v0.1.5: npm 11.13 was correctly used (so the
npm install -g npm@lateststep works), and the previousNODE_AUTH_TOKEN: XXXXX-XXXXX-XXXXX-XXXXXred herring is gone (so droppingregistry-urlworked). But npm CLI didn't even try OIDC — it just looked for a configured_authToken, found none, and gave up.Diagnosis
I had removed the
--provenanceflag in PR #32 based on npm's docs claiming "trusted publishers auto-detect, no flags needed". Empirically, that's wrong —--provenanceis what tells npm CLI to use the OIDC code path. Without it, npm only checks token-based auth and bails with ENEEDAUTH.Other npm-OIDC-publishing projects (Prettier, ESLint, …) all use
--provenanceexplicitly. I should have copied them, not the docs.What changes
npm publish --access publicnpm publish --access public --provenance --loglevel verboseACTIONS_ID_TOKEN_REQUEST_URL+ACTIONS_ID_TOKEN_REQUEST_TOKENare set--provenancewas redundantregistry-urlAND keep--provenance— both required, neither alone works--loglevel verboseis cheap insurance: if there's a third bug hiding behind this one, the next failure log will have enough detail to diagnose without re-running.v0.1.6 wave status
Same partial-state as v0.1.5: 4 of 5 packages shipped, npm one missing. After this PR merges I'll cut v0.1.7. The previous failed npm tag (
sqlrite-node-v0.1.6) and missing umbrella (v0.1.6) stay as they are per never-reuse-a-version policy.Test plan
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/release.yml'))"— YAML parsesACTIONS_ID_TOKEN_REQUEST_URL is set: yesin the diagnostics step (confirms GHA injected the OIDC env)@joaoh82/sqlrite@0.1.7on npmnpm view @joaoh82/sqlriteshows the new versionnpm audit signaturespasses against the sigstore attestationIf publish-nodejs fails again, the verbose npm log will show exactly what npm tried (token vs OIDC) and where it failed.
🤖 Generated with Claude Code