Repository navigation
ci(release): pin publish job to a named environment and tag refs - #58
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 |
🤖 CodeAnt AI — Review Status
|
Reviewer's GuideThe release workflow now prevents the OIDC credential-minting publish job from running on arbitrary branch refs, while retaining tag and default-branch backfill workflows. It also documents the existing job-scoped Flow diagram for guarded publish jobflowchart TD
A[Release workflow event] --> B{publish if guard}
B -->|v* tag push| C[resolve-ref and verify]
B -->|published release| C
B -->|workflow dispatch from default branch| C
B -->|other branch or ref| X[Publish job skipped]
C --> D[Publish job]
D --> E[pypi environment]
E --> F[OIDC token with id-token write]
F --> G[PyPI publish]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
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_e7897477-2316-4872-8354-0cd10e89ef6b) |
|
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: 6 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 now limits the credential-minting ChangesRelease publishing controls
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The publish guard restricts credential issuance to the intended release contexts, and the permitted default-branch dispatch remains usable. 🚥 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
ApprovabilityVerdict: Not approved Macroscope's review found this PR not approvable — The change restricts PyPI publishing credentials to approved refs, altering the authorization boundary for production package publication while leaving normal SDK runtime behavior unchanged. Its release and OIDC implications warrant focused human review despite the narrow, owner-authored diff. Not approved because:
Review your spending limits in Billing settings. You can add or adjust custom eligibility rules. Learn more. |
![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. This changes the authorization and trust boundary for minting a PyPI publishing credential: a condition or environment/OIDC mismatch could let an unapproved ref publish a package. Reverting would stop future unauthorized runs, but any package already published under the wrong authorization would remain externally visible and require remediation.
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| if: >- | ||
| startsWith(github.ref, 'refs/tags/v') | ||
| || github.event_name == 'release' | ||
| || github.ref == format('refs/heads/{0}', github.event.repository.default_branch) |
There was a problem hiding this comment.
Suggestion: A dispatch from main passes this guard, but the documented tag-only pypi environment policy rejects that branch ref before publishing, breaking the backfill path. [api mismatch]
Assessment: 🟠 Major · 🔁 Occurrence: Sometimes
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** .github/workflows/release.yml
**Line:** 282:282
**Comment:**
*Api Mismatch: A dispatch from `main` passes this guard, but the documented tag-only `pypi` environment policy rejects that branch ref before publishing, breaking the backfill path.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
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 ✅ ApprovedAdds a ref guard to the 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 |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
2 issues found across 1 file
Confidence score: 3/5
- In
.github/workflows/release.yml, the branch condition allows a default-branch dispatch to reach the publish job, but the tag-onlypypienvironment blocks it before publishing, so the documented backfill path cannot work; make the dispatch path compatible with the environment protection or revise the documented procedure. - The
github.event_name == 'release'condition in.github/workflows/release.ymlis unreachable because the workflow only triggers on tag pushes andworkflow_dispatch; remove the dead clause or add the corresponding event trigger.
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:281">
P2: The `github.event_name == 'release'` clause is dead: this workflow's `on:` block (lines 70-73) only triggers on tag pushes and `workflow_dispatch` — no `release` event trigger exists, so A `release` event can never start this run and the clause can never be true. The added guard comment and the PR description both claim a "published release" is a supported publish path, which is misleading. If release-event triggering is intended, add `on: release: types: [published]` and gate the job on `github.event.action == 'published'`; if not, remove the clause and the 'published release' claim. Note that default `on: release` types are `published`, `created`, `edited`, `deleted`, `unpublished`, `prereleased` — a future add without an explicit `types:` list would let this broad clause pass the id-token:write guard on release deletion/edits, the opposite of this PR's fail-closed intent.</violation>
<violation number="2" location=".github/workflows/release.yml:282">
P1: When the `pypi` environment allows only tag deployments, this branch clause lets a default-branch dispatch reach the job but environment protection blocks it before publishing, so the documented backfill path cannot work. Allow the default branch in the `pypi` environment deployment policy.</violation>
</file>
Architecture diagram
sequenceDiagram
participant GH as GitHub Events
participant WF as Release Workflow
participant RR as resolve-ref Job
participant V as verify Job
participant P as publish Job
participant ENV as pypi Environment
participant OIDC as GitHub OIDC Provider
participant ACT as Actions Cache
participant PYPI as PyPI Trusted Publisher
Note over GH,PYPI: Current-State Release Pipeline Security Model
GH->>WF: Trigger workflow run
WF->>RR: Run resolve-ref job
RR->>RR: Validate tag is v<semver>
RR->>RR: Verify tag resolves to commit
RR->>RR: Confirm commit is ancestor of origin/main
alt Tag validation fails
RR-->>WF: Skip downstream jobs
else Tag validation succeeds
RR-->>V: Pass validated tag info
V->>V: Run verification checks
V-->>P: Trigger publish job
end
Note over P: Ref guard on publish job
alt v* tag push (github.ref startsWith refs/tags/v)
P->>ENV: Request pypi environment
else Published release event
P->>ENV: Request pypi environment
else workflow_dispatch from default branch
P->>ENV: Request pypi environment
else Other branch dispatch
P-->>WF: Job skipped - no credential minted
end
Note over P,ENV: Environment protection gate
alt Environment protection rules pass
ENV-->>P: Grant environment access
P->>OIDC: Requestid-token (job-scoped write)
OIDC-->>P: Mint token with run's ref claim
P->>ACT: Access branch-scoped cache
P->>PYPI: Publish package with OIDC token
PYPI-->>P: Confirm publication
else Protection rules deny
ENV-->>P: Block credential minting
end
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| if: >- | ||
| startsWith(github.ref, 'refs/tags/v') | ||
| || github.event_name == 'release' | ||
| || github.ref == format('refs/heads/{0}', github.event.repository.default_branch) |
There was a problem hiding this comment.
P1: When the pypi environment allows only tag deployments, this branch clause lets a default-branch dispatch reach the job but environment protection blocks it before publishing, so the documented backfill path cannot work. Allow the default branch in the pypi environment deployment policy.
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 282:
<comment>When the `pypi` environment allows only tag deployments, this branch clause lets a default-branch dispatch reach the job but environment protection blocks it before publishing, so the documented backfill path cannot work. Allow the default branch in the `pypi` environment deployment policy.</comment>
<file context>
@@ -266,11 +266,32 @@ jobs:
+ if: >-
+ startsWith(github.ref, 'refs/tags/v')
+ || github.event_name == 'release'
+ || github.ref == format('refs/heads/{0}', github.event.repository.default_branch)
runs-on: ubuntu-latest
timeout-minutes: 10
</file context>
| # `refs/heads/`, matching no real ref, so the guard fails CLOSED. | ||
| if: >- | ||
| startsWith(github.ref, 'refs/tags/v') | ||
| || github.event_name == 'release' |
There was a problem hiding this comment.
P2: The github.event_name == 'release' clause is dead: this workflow's on: block (lines 70-73) only triggers on tag pushes and workflow_dispatch — no release event trigger exists, so A release event can never start this run and the clause can never be true. The added guard comment and the PR description both claim a "published release" is a supported publish path, which is misleading. If release-event triggering is intended, add on: release: types: [published] and gate the job on github.event.action == 'published'; if not, remove the clause and the 'published release' claim. Note that default on: release types are published, created, edited, deleted, unpublished, prereleased — a future add without an explicit types: list would let this broad clause pass the id-token:write guard on release deletion/edits, the opposite of this PR's fail-closed intent.
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 281:
<comment>The `github.event_name == 'release'` clause is dead: this workflow's `on:` block (lines 70-73) only triggers on tag pushes and `workflow_dispatch` — no `release` event trigger exists, so A `release` event can never start this run and the clause can never be true. The added guard comment and the PR description both claim a "published release" is a supported publish path, which is misleading. If release-event triggering is intended, add `on: release: types: [published]` and gate the job on `github.event.action == 'published'`; if not, remove the clause and the 'published release' claim. Note that default `on: release` types are `published`, `created`, `edited`, `deleted`, `unpublished`, `prereleased` — a future add without an explicit `types:` list would let this broad clause pass the id-token:write guard on release deletion/edits, the opposite of this PR's fail-closed intent.</comment>
<file context>
@@ -266,11 +266,32 @@ jobs:
+ # `refs/heads/`, matching no real ref, so the guard fails CLOSED.
+ if: >-
+ startsWith(github.ref, 'refs/tags/v')
+ || github.event_name == 'release'
+ || github.ref == format('refs/heads/{0}', github.event.repository.default_branch)
runs-on: ubuntu-latest
</file context>
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 hands it to a package registry. Two lines of behaviour, no change to what gets built, tested, or uploaded.1. 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 av*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 fork branch, a scratch branch — stops at this job instead of requesting the environment and reaching the registry.2. A comment making the existing environment and permission scoping non-accidental. The named environment and the job-scoped
id-token: writewere already correct here; they are now documented as load-bearing so a future edit does not hoist the mint to the workflow level or drop the environment name that the registry-side publisher configuration is pinned to.Why the ref guard is not redundant with the checks already here
The
resolve-refjob already does real work: it validates the tag against a full-anchoredv<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 OIDC token the runner mints, 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
refs/tags/v*-only guard would have been simpler and wrong. This workflow has a deliberate, documented idempotent-backfill path: an operator dispatches it from the default branch naming an already-shipped tag, and the pipeline re-runs without re-publishing (the registry-version check already no-ops the upload for a version that exists). 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 also 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.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,verify,publish,sbom,release.publishjob asserts, post-change:environment=pypi,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 publisher is pinned to the same environment name, 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
Medium Risk
Changes release pipeline authorization for PyPI OIDC publishing; misconfigured conditions could block legitimate backfills or leave a gap if expressions are wrong, though the intent is fail-closed.
Overview
Tightens who can mint PyPI publishing credentials in the release workflow by adding a job-level
if:onpublish. That job now runs only forv*tag pushes, published GitHub releases, orworkflow_dispatchfrom the default branch—blocking dispatches from feature or fork branches that could still pass tag ancestry checks while putting the run’s OIDCrefand Actions cache under an untrusted branch identity.The diff is otherwise comment-only documentation around the existing
pypienvironment and job-scopedid-token: write, so future edits don’t hoist OIDC minting to workflow scope or drop the environment name PyPI Trusted Publishing expects.Reviewed by Cursor Bugbot for commit 9947140. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by Sourcery
Harden the release workflow by limiting publishing credentials to approved refs while preserving the default-branch backfill path.
Enhancements:
CI:
CodeAnt-AI Description
Restrict PyPI publishing to approved release refs and environment controls
What Changed
pypienvironment so its configured protection rules and registry trust settings can gate credential issuanceImpact
✅ Fewer accidental PyPI publications✅ Release credentials limited to approved refs✅ Environment review gates protected publishing💡 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.