ci: make DPU releases transactional - #215
Conversation
Separate reviewed version proposals from tag-driven publication so failed packaging cannot leave a public release without assets. Validate manifest, lockfile, tag ancestry, Debian metadata, and checksums before publishing, and fix the package README path exposed by 2.2.1.
|
Warning Review limit reached
Next review available in: 31 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughThe PR replaces pull-request release creation with validated semantic-tag releases. It adds synchronized version-bump automation, release verification, Debian package validation, checksum generation, pinned workflow actions, locked Cargo commands, and expanded script tests. ChangesRelease automation
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant MergedPR
participant VersionBumpWorkflow
participant update.py
participant VersionBumpPR
participant ReleaseWorkflow
participant verify_release.py
participant cargo_deb
participant GitHubRelease
MergedPR->>VersionBumpWorkflow: merge into main
VersionBumpWorkflow->>update.py: update manifest and lockfile
VersionBumpWorkflow->>VersionBumpPR: create or update automation pull request
VersionBumpPR->>ReleaseWorkflow: merged version bump creates semantic tag
ReleaseWorkflow->>verify_release.py: verify tag and package versions
ReleaseWorkflow->>cargo_deb: build and validate Debian package
ReleaseWorkflow->>GitHubRelease: publish package and checksum assets
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/release.yml:
- Around line 41-42: Pin Python 3.11 or newer with an actions/setup-python step
before Python usage in .github/workflows/release.yml (lines 41-42) and
.github/workflows/rust.yml (lines 20-21), ensuring the release validation and
script tests invoke the configured interpreter instead of unversioned python3.
- Around line 37-40: Update the release-existence check around gh release view
"$TAG" to distinguish draft releases from published releases. Allow a retry to
reuse or cleanly complete an existing draft before attempting publication, while
continuing to fail when a published release already exists.
In @.github/workflows/version-bump.yml:
- Around line 17-20: Update the workflow condition guarding the version-bump job
to require the merged pull request’s head repository to match github.repository,
preventing fork PRs from triggering it. In the gh pr list filtering logic,
additionally require headRepository.nameWithOwner to equal github.repository
before selecting or editing the automation/version-bump PR.
🪄 Autofix
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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 489a885e-492c-4381-b87f-2e4f3ef6fab1
📒 Files selected for processing (8)
.github/workflows/release.yml.github/workflows/rust.yml.github/workflows/version-bump.ymlscripts/test_update.pyscripts/test_verify_release.pyscripts/update.pyscripts/verify_release.pyvibi-dpu/Cargo.toml
Pin Python 3.11 for tomllib-based validation, resume interrupted draft releases without accepting published duplicates, and restrict version-bump automation to same-repository pull requests and bot branches.
1 participant
Why
The post-merge automation for #213 published tag/release
2.2.1before packaging completed.cargo debthen failed becausevibi-dpu/Cargo.tomlresolvedREADME.mdinside the crate while the file is at repository root. The result is an immutable tag pointing at source that still declares 2.2.0, an open unchecked bump PR (#214), and a public release with no assets.This PR makes release publication fail closed: a normal merge may only propose a reviewed version change; only an explicit
vMAJOR.MINOR.PATCHtag on a commit already contained inmaincan package and publish a release.Changes
cargo-deb;Cargo.tomlandCargo.lockin the version proposal script, skipping versions already present as either legacy orvtags;cargo-debversion;.debbefore creating a draft release, then publish only after assets upload successfully;Recovery boundary
2.2.1is intentionally untouched and should be treated as incomplete/superseded.Cargo.toml, has no checks, and cannot repair the already-published 2.2.1 release.mainshould a deliberatev2.2.2tag be created. The new tag workflow will build and publish the validated.debplus checksum.Verification
python3 -m unittest scripts/test_update.py scripts/test_verify_release.py— 8 passedcargo metadata --manifest-path vibi-dpu/Cargo.toml --locked --no-deps --format-version 1— passedcargo test --manifest-path vibi-dpu/Cargo.toml --locked— 1 passed; 96 pre-existing warningscargo build --manifest-path vibi-dpu/Cargo.toml --release --locked— passed; same pre-existing warningscargo package --manifest-path vibi-dpu/Cargo.toml --locked --allow-dirty --no-verify --list— passedcargo deb --manifest-path vibi-dpu/Cargo.toml --lockedwith cargo-deb 3.7.0 — produced and inspectedvibi-dpu_2.2.0-1_amd64.deb; payload contains/usr/bin/vibi-dpugit diff --checkpassedThe independent multi-architecture GHCR run for merge commit
3950199completed successfully; its immutable image remains separate from semantic release 2.2.2.Summary by CodeRabbit
New Features
Bug Fixes
Chores