Repository navigation
chore: rolling promotion dev -> main - #2646
Conversation
The org-wide deploy-key ban made the ssh model unusable, and the fine-grained PAT that replaced it still could not push: the 'main' ruleset carried a pull_request rule with an empty bypass_actors list, so every direct push was rejected GH013 regardless of token scope. That froze the channel pointers from 2026-07-20 onward. Resolved without touching the deploy-key policy: PR #2643 (promoted in #2644 as 73bd48a) mints a per-run GitHub App token — genie-release-bot, app id 4393439, contents:write + metadata:read only, installed on this repository alone, sole ruleset bypass actor Integration:4393439:always. No user, role, or Actions bypass was added, and the token expires in ~1h so no long-lived credential can push to main. The dev/homolog criterion stays UNCHECKED until a post-merge dev release actually advances a channel manifest — this commit is that release's trigger.
…-unblocked docs(wish): record release-manifest credential resolution (stable gate)
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughRelease workflows now carry the triggering CI commit separately from the built version commit, use it for automated provenance verification, and test the updated identity rules. Release metadata is bumped to ChangesRelease provenance and metadata
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant VersionWorkflow
participant ReleaseWorkflow
participant SignAttest
participant ReleasePublish
participant ProvenanceScript
VersionWorkflow->>ReleaseWorkflow: pass workflow_run.head_sha as trigger_sha
ReleaseWorkflow->>SignAttest: pass trigger_sha
ReleaseWorkflow->>ReleasePublish: pass trigger_sha
ReleasePublish->>ProvenanceScript: provide SOURCE_SHA and TRIGGER_SHA
ProvenanceScript->>ProvenanceScript: verify workflow_run.head_sha against TRIGGER_SHA
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…t commit Every dev release since 2026-07-25 has failed at sign-attest, silently: verify_exact exits 1 with no message immediately after 'PASSED: SLSA verification passed', killing all four Sign jobs and skipping publish. verify_automated_event asserted $run.head_sha == $source_sha, where $run is the CI workflow_run that TRIGGERED the release and source_sha is the commit the tarballs were built from. Those are never equal on an automated release: auto-version commits the version bump after CI, and the build runs from that bump commit. Observed on v5.260725.4 — CI run 30173890949 head 7b08499, SOURCE_SHA 0466b43, whose parent is exactly 7b08499. The assertion is unsatisfiable by construction. release-publish.yml carried the same defect one stage later, comparing the generic descriptor's sourceSha (also the trigger head) against SOURCE_SHA — it would have failed as soon as signing was fixed. - plumb trigger_sha (github.event.workflow_run.head_sha) through version.yml -> release.yml -> sign-attest.yml + release-publish.yml, optional so the stable dispatch path is unaffected - verify_automated_event binds head_sha to TRIGGER_SHA and requires a well-formed one whenever exact verification is demanded; run id still pins the admitting run exactly, so no binding is lost - release-publish.yml compares the generic descriptor against TRIGGER_SHA for dev/homolog and SOURCE_SHA for stable; the native predicate records source_sha directly and stays compared against it - the test fixture set head_sha = SOURCE_SHA, modelling an impossible world, which is why this shipped; it now models the real one and gains a regression test covering forged, absent, and malformed triggers Not caused by the App-token change: the first failure (16:55) predates that fix reaching main (20:01).
fix(release): bind provenance to the triggering CI head, not the built commit
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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.
Inline comments:
In @.github/workflows/sign-attest.yml:
- Line 340: Pass TRIGGER_SHA from inputs.trigger_sha into the environment of the
later Verify SLSA provenance step that invokes verify-exact, not only the
current step-scoped environment. Preserve the existing value and ensure the
generic provenance self-check receives it for dev/homolog releases.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 3cae0a9f-1140-4192-91c1-cd2b40a407fd
📒 Files selected for processing (6)
.github/workflows/release-publish.yml.github/workflows/release.yml.github/workflows/sign-attest.yml.github/workflows/version.ymlscripts/release-generic-provenance.shscripts/release-generic-provenance.test.ts
Rolling Promotion PR
Auto-maintained rolling promotion PR from
devtomain.Process:
ready-to-mergeadded when all checks passSummary by CodeRabbit
trigger_shainput and validating generic provenance against the channel-appropriate trigger identity.