ci(release): opt into npm OIDC Trusted Publishing

[Yan Xue (yanxue06)]

Summary

Token-based npm publishing has been silently failing for spectrum-ts since v1.10.0. The org-level NPM_TOKEN was invalidated on the npm.com side sometime between 2026-05-19 and 2026-05-21, and bunx clean-publish swallowed the resulting npm error code E404 exit, so four GitHub releases (v1.10.0, v1.10.1, v1.11.0, v1.11.1) shipped to GitHub but never landed on npm — npm latest is still 1.9.2.

This PR moves spectrum-ts to npm OIDC Trusted Publishing so future releases authenticate with a per-run GitHub-issued OIDC token instead of a long-lived secret. No more rotating-token-secret class of failure.

Changes

• permissions: add id-token: write (required for the runner to mint the OIDC token).
• with: add use-oidc: true so buildspace's typescript-service-release workflow routes through the OIDC publish job.

The buildspace publish-npm block already prefers OIDC when id-token is available and falls back to NPM_TOKEN otherwise, so this is safe — if Trusted Publisher isn't configured yet on the npm side, the publish silently no-ops the way it has been (until photon-hq/buildspace#82 lands, which makes that case hard-fail).

Required pre-merge action on npmjs.com

Trusted Publisher must be configured for the spectrum-ts package before this PR is merged with a release label, otherwise OIDC will fail and the publish will fall back to the still-broken token. As maintainer photon_dev:

1. Visit https://www.npmjs.com/package/spectrum-ts/access
2. Scroll to Trusted Publisher → Add publisher
3. Fill in:
   • Publisher: GitHub Actions
   • Organization or user: photon-hq
   • Repository: spectrum-ts
   • Workflow filename: release.yaml
   • Environment: (leave blank)
4. Save

Test plan

• Configure Trusted Publisher on npmjs.com (above)
• Merge this PR (no release label) — confirms workflow YAML still parses on push to main
• Open a follow-up no-op PR (e.g., a docs tweak) with the release label
• Watch the release run: npm-publish-oidc job should run instead of npm-publish, and the verify-on-registry step (after fix(publish-npm): make silent publish failures structurally impossible buildspace#82) should report <name>@<version> is live on the npm registry
• Confirm curl https://registry.npmjs.org/spectrum-ts | jq '."dist-tags".latest' shows the new version

Background

Detailed root-cause analysis: every release run since v1.10.0 shows npm error 404 - PUT https://registry.npmjs.org/spectrum-ts - Not found (npm returns 404 instead of 401/403 for auth failures), but the step still reports [success] because bunx clean-publish doesn't propagate npm's non-zero exit. Counter-evidence: org-level NPM_TOKEN secret's updated_at is 2026-05-11, well before 1.9.2 published cleanly on 2026-05-19, so the GitHub-side secret value never changed — the token itself was invalidated on npm.

Made with Cursor

---

^{Need help on this PR? Tag @codesmith with what you need. Autofix is disabled.}

Summary by CodeRabbit

• Chores
  • Updated release workflow security configuration to enhance deployment processes.

[coderabbitai]

📝 Walkthrough

Walkthrough

The release workflow is updated to enable OpenID Connect (OIDC) authentication by adding id-token write permission to the job and configuring the reusable workflow invocation with use-oidc: true.

Changes

Release Workflow OIDC Setup

Layer / File(s)	Summary
Enable OIDC in release workflow .github/workflows/release.yaml	Job permissions are granted id-token write access, and the buildspace TypeScript service release workflow invocation is configured with use-oidc: true to enable OIDC authentication.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Suggested labels

release

Suggested reviewers

• underthestars-zhy

Poem

A token of trust, exchanged with care,
OIDC flows through the workflow air,
Permissions granted, a secure way,
Build and release, now safer today! 🐰✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically summarizes the main change: enabling npm OIDC Trusted Publishing in the CI release workflow, which directly matches the changeset modifications to add OIDC permissions and configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/enable-oidc-publishing

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/release.yaml (1)

10-10: ⚡ Quick win

Consider moving id-token: write to job-level permissions.

The id-token: write permission is only needed by the release job. Scoping it at the job level instead of workflow level follows the principle of least privilege and makes the intent clearer.

🔐 Proposed job-level permissions

Remove from workflow-level permissions:

 permissions:
   contents: write
   pull-requests: read
-  id-token: write

Add to the release job:

 jobs:
   release:
+    permissions:
+      contents: write
+      pull-requests: read
+      id-token: write
     uses: photon-hq/buildspace/.github/workflows/typescript-service-release.yaml@main

As per coding guidelines, the static analysis tool zizmor flagged "id-token: write is overly broad at the workflow level".

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yaml at line 10, Move the workflow-level
permission "id-token: write" down into the specific job that needs it: the
release job; remove the global permissions entry "id-token: write" and add the
same permission under the release job's permissions block so only the release
job has id-token write access (look for the workflow permissions section and the
job named "release" to update).

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/workflows/release.yaml:
- Line 10: Move the workflow-level permission "id-token: write" down into the
specific job that needs it: the release job; remove the global permissions entry
"id-token: write" and add the same permission under the release job's
permissions block so only the release job has id-token write access (look for
the workflow permissions section and the job named "release" to update).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b51115c6-a8c7-4c10-a301-17295e5e891c

📥 Commits

Reviewing files that changed from the base of the PR and between 2528996 and 6095e79.

📒 Files selected for processing (1)

• .github/workflows/release.yaml

📜 Review details

🧰 Additional context used

🪛 zizmor (1.25.2)

.github/workflows/release.yaml

[error] 10-10: overly broad permissions (excessive-permissions): id-token: write is overly broad at the workflow level

(excessive-permissions)

🔇 Additional comments (1)

.github/workflows/release.yaml (1)

20-20: LGTM!

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.