ci: switch npm publish to OIDC trusted publishing#8454
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 399c29f2fe
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- Add workflow_call trigger to publish-npm.yml so it can be called from release.yml - Remove the push-to-main trigger (publishing now only happens via release.yml or manual workflow_dispatch) - Add publish-npm job to release.yml after the release job - Simplify publish conditions to only check dry-run input (the environment deployment branch rules handle branch protection) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3c06df7a2b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| publish-npm: | ||
| needs: [release] | ||
| uses: ./.github/workflows/publish-npm.yml |
There was a problem hiding this comment.
This new call wires npm publishing into the tag-based Release pipeline, but the called workflow now enforces the npm-production-publishing environment, whose own header docs specify deployment is restricted to branch main; for release runs triggered from refs/tags/v1.*, that environment gate will reject the job before publish executes. In practice, this means tagged releases can create GitHub releases while npm publication is blocked, so the release flow becomes partially broken.
Useful? React with 👍 / 👎.
- Remove build-goose-binaries job; fetch pre-built binaries from GitHub release instead using gh release download - Add required release-tag input to workflow_call and workflow_dispatch - Remove dry-run input and all associated steps - Remove skip-cache input (no longer relevant) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 82fb20dd32
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
.github/workflows/publish-npm.yml
Outdated
| artifact="goose-${target}.zip" | ||
| gh release download "${TAG}" --pattern "${artifact}" --dir /tmp | ||
| unzip -o "/tmp/${artifact}" -d /tmp/goose-extract | ||
| cp /tmp/goose-extract/goose.exe "${pkg_dir}/goose.exe" |
There was a problem hiding this comment.
The Windows branch copies /tmp/goose-extract/goose.exe, but in the checked release pipeline (.github/workflows/build-cli.yml), the zip is created with 7z ... goose-package/, so extraction places the executable at .../goose-package/goose.exe. On any run that includes win32-x64, this cp path is missing and the release job fails before pnpm publish, blocking npm publication.
Useful? React with 👍 / 👎.
Sync all @aaif/* package versions past the 0.13.0 currently published on npm. Remove stale initial-release changeset. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5ae724689c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
.github/workflows/publish-npm.yml
Outdated
| artifact="goose-${target}.zip" | ||
| gh release download "${TAG}" --pattern "${artifact}" --dir /tmp | ||
| unzip -o "/tmp/${artifact}" -d /tmp/goose-extract | ||
| cp /tmp/goose-extract/goose.exe "${pkg_dir}/goose.exe" |
There was a problem hiding this comment.
The Windows download path assumes the zip extracts goose.exe at the root, but this commit’s release artifacts are packaged with a goose-package/ directory. Fresh evidence: .github/workflows/build-cli.yml creates the zip via 7z ... goose-package/, so after unzip the executable is at .../goose-package/goose.exe; this cp path fails for win32-x64, aborting npm publication.
Useful? React with 👍 / 👎.
| type: string | ||
| workflow_dispatch: | ||
| inputs: | ||
| dry-run: |
There was a problem hiding this comment.
worth keeping dry-run perhaps, or no in your view?
There was a problem hiding this comment.
Yeah, I'll add it back. Removed because the whole job set the environment anyway, but we can change this so the publish part is its own job so the whole thing is testable without publish and without the environment constraint
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 46fcd85ca5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4 | ||
| with: | ||
| name: npm-packages | ||
| path: ui/ |
There was a problem hiding this comment.
Uploading the entire ui/ tree as an artifact here introduces a permissions regression for Unix binaries: actions/upload-artifact/download-artifact does not preserve executable mode, so bin/goose can be republished as non-executable after the build→publish handoff. That makes installed @aaif/goose-binary-* packages fail at runtime when @aaif/goose tries to spawn the resolved binary path (ui/text/src/tui.tsx), typically with EACCES on macOS/Linux. Re-applying chmod +x before pnpm publish (or artifacting a tarball that preserves modes) avoids shipping broken binaries.
Useful? React with 👍 / 👎.
2 participants
Summary
Switch the npm publish workflow from using a long-lived
NPM_PUBLISH_TOKENsecret to OIDC-based trusted publishing. GitHub Actions now authenticates directly with npm using short-lived OIDC tokens issued to thenpm-production-publishingenvironment, eliminating the need for stored npm access tokens.Changes:
environment: npm-production-publishingto the release jobConfigure npm authenticationstep that wrote the token to.npmrcNODE_AUTH_TOKEN/NPM_PUBLISH_TOKENreferences from the publish step--provenanceflag directly topnpm publishTesting
Requires a dry-run workflow dispatch to verify OIDC token issuance works end-to-end. The
npm-production-publishingenvironment claims have already been configured on npm.Related Issues
N/A