fix: add last-release-sha to Release Please config#461
Conversation
Scorecard's Signed-Releases check classifies .sigstore.json as a signature artifact but not as provenance. Extract the DSSE envelope from the Sigstore bundle and upload it as checksums.txt.intoto.jsonl, which Scorecard recognises as SLSA provenance.
Add -e flag to jq so the step exits non-zero if .dsseEnvelope is null or absent, preventing upload of an invalid .intoto.jsonl to an immutable release.
Release Please kept computing v0.2.0 instead of the next patch because manual version resets during the v0.2.4 recovery corrupted its commit history walk. Pin last-release-sha to the v0.2.5 tag commit so it only considers commits after that baseline.
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical issue in the release automation process by correcting the behavior of Release Please. Following a manual version reset, Release Please was incorrectly computing versions from the repository's beginning, leading to spurious release proposals. By anchoring Release Please to a specific historical commit, this change ensures accurate versioning and prevents the creation of erroneous release pull requests, thereby streamlining the release workflow. Highlights
Changelog
Ignored Files
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📜 Recent review details⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🧰 Additional context used📓 Path-based instructions (1).github/workflows/cli.yml📄 CodeRabbit inference engine (CLAUDE.md)
Files:
🧠 Learnings (9)📓 Common learnings📚 Learning: 2026-03-15T18:36:58.934ZApplied to files:
📚 Learning: 2026-03-15T18:36:58.934ZApplied to files:
📚 Learning: 2026-03-15T18:36:58.934ZApplied to files:
📚 Learning: 2026-03-15T18:36:58.934ZApplied to files:
📚 Learning: 2026-03-15T18:36:58.934ZApplied to files:
📚 Learning: 2026-03-15T11:48:14.867ZApplied to files:
📚 Learning: 2026-03-15T18:36:58.934ZApplied to files:
📚 Learning: 2026-03-15T18:36:58.934ZApplied to files:
🔇 Additional comments (2)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe changes add a last-release-sha tracking entry to the release configuration and modify the CLI release workflow to extract the DSSE envelope from the attestation bundle and include the extracted data as a release asset. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
📝 Coding Plan
Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds last-release-sha to the Release Please configuration to fix an issue with incorrect release versioning. The change is correct and well-explained. I have one suggestion regarding the long-term maintainability of this configuration file.
| "release-type": "python", | ||
| "package-name": "synthorg", | ||
| "include-component-in-tag": false, | ||
| "last-release-sha": "24a0d7aca1eb1b594a821581cf6a1ecc38c3e4c8", |
There was a problem hiding this comment.
As noted in the pull request description and the release-please documentation, last-release-sha is a one-time anchor. To maintain a clean configuration and prevent potential confusion for future maintainers, it's advisable to remove this line after the next release has been successfully created. Please consider creating a follow-up ticket to track this cleanup task.
|
Wrong fix. The real solution is force-tag-creation: true in Release Please config. |
1 participant
Summary
last-release-shapointing to the v0.2.5 tag commit to Release Please configContext
The v0.2.4 recovery (manual version reset) corrupted Release Please's commit history walk, causing it to compute versions from the beginning of the repo instead of from the last tag. The
last-release-shafield is a one-time anchor that tells Release Please where to start looking.Test plan