Conversation
The publish job is the only job that mints a short-lived OIDC identity and exchanges it for a registry publish credential. Declare a named environment on that job so the registry-side trusted publisher and a repository environment protection rule have something to pin to, and add an if: guard so the job runs only from a release tag push, a published release, or a default-branch dispatch (the documented idempotent backfill path) -- never from an arbitrary branch. The existing resolve-ref job validates the TAG (shape, existence, ancestry to origin/main), which governs the code that gets published. It says nothing about the run own ref, which is what lands in the OIDC token ref claim and scopes the run Actions cache. This guard closes that gap. id-token: write stays scoped to this job only; the workflow-level default remains contents: read. Verified locally (org Actions runs are not executing): actionlint exit 0, YAML parses, job graph unchanged, additive diff only. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
ⓘ Qodo reviews are paused because your workspace is out of credits. Ask your workspace admin to add credits to resume reviews. Manage billing |
Reviewer's GuideThe release workflow now gates its sole OIDC credential-minting job on trusted refs and binds it to the named npm environment, while preserving the existing build, verification, packaging, upload, and backfill behavior and least-privilege permission boundaries. Flow diagram for the gated npm publish jobflowchart TD
Start[Release workflow run] --> Guard{Publish ref/event allowed?}
Guard -->|sdk-v* tag push| Publish[publish job]
Guard -->|published release| Publish
Guard -->|workflow dispatch on default branch| Publish
Guard -->|anything else| Skip[Publish skipped]
Publish --> Env[npm environment]
Env --> OIDC[Mint OIDC identity]
OIDC --> Registry[npm trusted publisher]
Registry --> Upload[Publish package]
Skip --> NoRelease[release job not created]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_d7523508-3ce2-4cd8-b64b-3f83fc42b9cb) |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: 5 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 10 reviews per hour. 📜 Recent review details⏰ Context from checks skipped due to timeout. (5)
🔇 Additional comments (1)
📝 SummarySummary by CodeRabbit
WalkthroughThe release workflow restricts the ChangesRelease publishing
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to Publishing remains available through the documented tag and manual-dispatch paths, with no actionable merge-blocking risk identified. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
codeant-ai
Bot
added
the
size:S
|
Note Automatic reviews are paused because your team has used its included automatic processing for this billing period (headroom scales with your seat count). You can still comment "Gitar review" to run one anytime, and automatic reviews resume on their own by October 1. Add seats for more headroom. Code Review ✅ ApprovedHardens the release workflow by pinning the npm publish job to a named environment and guarding it with a ref check that allows only SDK tag pushes, published releases, or dispatches from the default branch. This prevents arbitrary branch runs from minting publishing credentials while preserving the documented idempotent backfill path. No issues found. OptionsDisplay: compact → Counting what did not apply, without listing it. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Gitar |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've reviewed your changes and they look great!
Sourcery assessment
Needs a human reviewer. If the ref guard or named environment is misconfigured, an unintended workflow run could mint an npm publishing credential and publish under the trusted publisher identity. Reverting prevents future runs, but any package publication or credential-backed access that already occurred would require separate remediation.
ApprovabilityVerdict: Not approved Macroscope's review found this PR not approvable — This PR changes the production npm release workflow's credential-minting gate and environment protection boundary. The ref filter and named environment affect which runs can publish and depend partly on external repository/registry configuration, so the change warrants human review. Not approved because:
Review your spending limits in Billing settings. You can add or adjust custom eligibility rules. Learn more. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
3 issues found across 1 file
Confidence score: 3/5
- In
.github/workflows/release.yml, default-branch backfills cannot reach the documented tag-onlynpmenvironment because deployment uses the branch ref rather than thesdk-v...input; allow the default branch in that environment. - In
.github/workflows/release.yml, manual dispatches selecting ansdk-v*tag can satisfy a guard intended only for tag pushes; requiregithub.event_name == 'push'alongside the tag check. - In
.github/workflows/release.yml, thegithub.event_name == 'release'branch is unreachable because the workflow declares only tag pushes andworkflow_dispatch; remove or replace the dead condition to keep the guard aligned with configured triggers.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".github/workflows/release.yml">
<violation number="1" location=".github/workflows/release.yml:310">
P2: A manual dispatch whose selected ref is an `sdk-v*` tag also passes this clause, even though the guard promises to allow only a tag push. Require `github.event_name == 'push'` alongside `startsWith(...)` so dispatches cannot bypass the default-branch backfill boundary.</violation>
<violation number="2" location=".github/workflows/release.yml:311">
P2: The `github.event_name == 'release'` clause is dead code: release.yml's `on:` block only declares `push: tags ['sdk-v*']` and `workflow_dispatch` (lines 47-62), and this file is not a reusable workflow (no `workflow_call`), so no run of this workflow can ever have `event_name == 'release'`. The guard comment and the PR description advertise 'a published release' as a supported path that cannot actually occur. This doesn't widen access (release events never start the workflow), but it misrepresents the fail-closed guarantee in the one job that mints a publishing credential. Drop the clause or add the missing `release` trigger to `on:` if that path is genuinely intended.</violation>
<violation number="3" location=".github/workflows/release.yml:321">
P2: With the documented tag-only `npm` environment policy, a default-branch backfill never reaches this job because its deployment ref is the branch, not the `sdk-v...` input. Allow the default branch in that environment policy or use a tag-ref backfill path.</violation>
</file>
Architecture diagram
sequenceDiagram
participant GHA as GitHub Actions
participant Publish as Publish Job
participant Env as npm Environment
participant OIDC as OIDC Provider
participant NPM as npm Registry
Note over GHA,NPM: Release Pipeline - Publish Gate Flow
GHA->>Publish: Trigger workflow (event + ref)
alt Valid publish trigger
Note right of Publish: sdk-v* tag push OR release OR default branch dispatch
Publish->>Publish: Check if guard condition met
Publish->>Env: Request npm environment access
Env->>Env: Validate repository protection rules
alt Protection rules allow
Env-->>Publish: Environment approved
Publish->>OIDC: Request OIDC token (id-token: write)
OIDC-->>Publish: Token with environment:npm + ref claim
Publish->>NPM: Exchange OIDC token for publish credential
NPM-->>Publish: Authenticated
Publish->>NPM: Publish package
else Protection rules deny
Env-->>Publish: Denied
Publish->>GHA: Job skipped - no publish
end
else Invalid trigger
Note right of Publish: Feature branch dispatch or unexpected ref
Publish->>Publish: Guard fails closed
Publish->>GHA: Job skipped - no publish
end
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| # `refs/heads/`, matching no real ref, so the guard fails CLOSED. | ||
| if: >- | ||
| startsWith(github.ref, 'refs/tags/sdk-v') | ||
| || github.event_name == 'release' |
There was a problem hiding this comment.
P2: The github.event_name == 'release' clause is dead code: release.yml's on: block only declares push: tags ['sdk-v*'] and workflow_dispatch (lines 47-62), and this file is not a reusable workflow (no workflow_call), so no run of this workflow can ever have event_name == 'release'. The guard comment and the PR description advertise 'a published release' as a supported path that cannot actually occur. This doesn't widen access (release events never start the workflow), but it misrepresents the fail-closed guarantee in the one job that mints a publishing credential. Drop the clause or add the missing release trigger to on: if that path is genuinely intended.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/release.yml, line 311:
<comment>The `github.event_name == 'release'` clause is dead code: release.yml's `on:` block only declares `push: tags ['sdk-v*']` and `workflow_dispatch` (lines 47-62), and this file is not a reusable workflow (no `workflow_call`), so no run of this workflow can ever have `event_name == 'release'`. The guard comment and the PR description advertise 'a published release' as a supported path that cannot actually occur. This doesn't widen access (release events never start the workflow), but it misrepresents the fail-closed guarantee in the one job that mints a publishing credential. Drop the clause or add the missing `release` trigger to `on:` if that path is genuinely intended.</comment>
<file context>
@@ -296,8 +296,33 @@ jobs:
+ # `refs/heads/`, matching no real ref, so the guard fails CLOSED.
+ if: >-
+ startsWith(github.ref, 'refs/tags/sdk-v')
+ || github.event_name == 'release'
+ || github.ref == format('refs/heads/{0}', github.event.repository.default_branch)
runs-on: ubuntu-latest
</file context>
| # protection rule (required reviewer + tag-only deployment policy) gating | ||
| # the mint. Configuring that environment is an operator act, not this file. | ||
| environment: | ||
| name: npm |
There was a problem hiding this comment.
P2: With the documented tag-only npm environment policy, a default-branch backfill never reaches this job because its deployment ref is the branch, not the sdk-v... input. Allow the default branch in that environment policy or use a tag-ref backfill path.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/release.yml, line 321:
<comment>With the documented tag-only `npm` environment policy, a default-branch backfill never reaches this job because its deployment ref is the branch, not the `sdk-v...` input. Allow the default branch in that environment policy or use a tag-ref backfill path.</comment>
<file context>
@@ -296,8 +296,33 @@ jobs:
+ # protection rule (required reviewer + tag-only deployment policy) gating
+ # the mint. Configuring that environment is an operator act, not this file.
+ environment:
+ name: npm
+ url: https://www.npmjs.com/package/@wave-av/sdk
+ # `id-token: write` lives here and NOWHERE else; the workflow-level default
</file context>
| # -- and nothing else. A missing `default_branch` makes `format(...)` yield | ||
| # `refs/heads/`, matching no real ref, so the guard fails CLOSED. | ||
| if: >- | ||
| startsWith(github.ref, 'refs/tags/sdk-v') |
There was a problem hiding this comment.
P2: A manual dispatch whose selected ref is an sdk-v* tag also passes this clause, even though the guard promises to allow only a tag push. Require github.event_name == 'push' alongside startsWith(...) so dispatches cannot bypass the default-branch backfill boundary.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/release.yml, line 310:
<comment>A manual dispatch whose selected ref is an `sdk-v*` tag also passes this clause, even though the guard promises to allow only a tag push. Require `github.event_name == 'push'` alongside `startsWith(...)` so dispatches cannot bypass the default-branch backfill boundary.</comment>
<file context>
@@ -296,8 +296,33 @@ jobs:
+ # -- and nothing else. A missing `default_branch` makes `format(...)` yield
+ # `refs/heads/`, matching no real ref, so the guard fails CLOSED.
+ if: >-
+ startsWith(github.ref, 'refs/tags/sdk-v')
+ || github.event_name == 'release'
+ || github.ref == format('refs/heads/{0}', github.event.repository.default_branch)
</file context>
| startsWith(github.ref, 'refs/tags/sdk-v') | |
| github.event_name == 'push' && startsWith(github.ref, 'refs/tags/sdk-v') |
1 participant
User description
What this changes
One job in
.github/workflows/release.yml—publish, the only job in the pipeline that mints a short-lived OIDC identity and exchanges it for a registry publish credential. Two changes, no change to what gets built, tested, packed, or uploaded.1. The publish job now declares a named environment. It previously declared none.
environment: npmgives the run's OIDC token anenvironmentclaim, which is what lets the registry-side trusted-publisher configuration be pinned to that environment rather than accepting any workflow run from this repository. It is also the only hook a repository environment protection rule (required reviewer, tag-scoped deployment policy) can attach to — without a named environment there is nothing for such a rule to gate.2. A ref floor on the credential-minting job. The
publishjob now carries anif:guard and runs only when one of three things is true: the run is ansdk-v*tag push, the run is a published release, or the run is aworkflow_dispatchfrom the default branch. Anything else — a dispatch from a feature branch, a scratch branch — stops at this job instead of requesting the environment and reaching the registry.The job-scoped
id-token: writewas already correct and is unchanged; it is now commented as load-bearing so a future edit does not hoist it to the workflow level, where every job in the pipeline would inherit the ability to mint a publishing identity. The separate SBOM job deliberately holds repository write and never the mint; that separation is preserved.Why the ref guard is not redundant with the checks already here
The
resolve-refjob already validates the tag against a full-anchoredsdk-v<semver>regex, proves the tag resolves to a real commit object, and requires that commit to be an ancestor oforigin/main. That chain guarantees the code this pipeline publishes was merged and reviewed on the default branch. It deliberately says nothing about the run's own ref.That distinction matters, because the run's ref is not inert. It is the value that lands in the
refclaim of the minted OIDC token, and it is what scopes the run's Actions cache. Aworkflow_dispatchtriggered from an arbitrary branch would previously have satisfied every existing check — the tag it names is still ancestry-verified — while minting a publishing credential under that branch's identity and running inside that branch's cache scope. The guard closes exactly that gap and nothing else.Why the third clause exists
A strict tag-push-only guard would have been simpler and wrong. This workflow has a deliberate, documented idempotent-backfill path: a maintainer dispatches it from the default branch naming an already-published tag, and the pipeline replays without re-publishing (the already-published check already skips the upload) so a missing release or asset can be filled in. Dropping that path to satisfy a tidier condition would have traded a working operational capability for a cosmetic one. The default-branch clause keeps the backfill and still excludes every other branch; the ancestry check continues to anchor which tree that dispatch may act on.
The clause is written to fail closed:
format('refs/heads/{0}', github.event.repository.default_branch)yieldsrefs/heads/if the payload ever lacksdefault_branch, and that matches no real ref — so an unexpected event shape denies the publish rather than admitting it.Note the downstream effect is already handled: the release job is gated on
needs.publish.result == 'success', so a run where the guard denies publish leavespublishskipped and does not create a release either.Verification
Actions runs are not currently executing on this organisation, so this was verified locally rather than by a green check on this PR:
actionlint .github/workflows/release.yml— exit 0, no findings.resolve-ref,secret-scan,verify,publish,release,sbom.publishjob asserts, post-change:environment=npm,permissions={id-token: write, contents: read}, workflow-levelpermissions={contents: read}.Operator follow-up, not in this PR
This PR changes workflow files only. Naming an environment does not create it or protect it — that is repository configuration and is left entirely to a maintainer. Until the environment exists with a required reviewer and a tag-scoped deployment policy, and until the registry-side trusted publisher is updated to name the same environment, the
if:guard above is the active control and the environment name is a declaration awaiting its other half.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Note
Cursor Bugbot is generating a summary for commit cfd152a. Configure here.
Summary by Sourcery
Harden the release workflow by constraining publishing runs and associating npm publication with a named environment.
Bug Fixes:
Enhancements:
CodeAnt-AI Description
Restrict npm publishing to approved release contexts
What Changed
sdk-v*tag pushes, published releases, or manual runs from the default branchnpmenvironment, enabling environment-specific trusted publishing and approval controlsImpact
✅ Fewer unauthorized publish attempts✅ Environment-gated npm releases✅ Reduced publishing credential exposure💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.