fix: restore '~' in pre-release deb filenames before apt push#445
fix: restore '~' in pre-release deb filenames before apt push#445maqeel75 wants to merge 2 commits into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe ChangesAPT filename repair
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Up to standards ✅🟢 Issues
|
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/publish.yml:
- Around line 237-239: Update the renaming logic around the canonical variable
and mv command to detect when the destination canonical .deb already exists
before moving. Fail the workflow with a clear error instead of overwriting the
existing file, while preserving the no-op behavior when f already matches
canonical.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a2cdcef1-f2b2-465d-a4fb-8f5e8a2efb64
📒 Files selected for processing (1)
.github/workflows/publish.yml
GitHub Releases sanitizes
~→.in asset filenames on upload, so apre-release deb goreleaser builds as
...~rc1-1...is served from therelease as
...\.rc1-1.... reprepro pools debs under their canonical<Package>_<Version>_<Arch>.debname (which keeps the~), so thesanitized download name no longer matches the pooled name.
On a re-push of an already-published pre-release, the apt-repo-builder
moves the pooled
~copy into its staging dir and copies the.download alongside it. Because the names differ, the copy doesn't
replace the pooled copy, so reprepro receives two files for the same
version with different bytes and fails:
ERROR: '...~rc1-1.bookworm_amd64.deb' cannot be included ...
Already existing files can only be included again, if they are the same
Fix
After
gh release download, rebuild each deb's canonical filename fromits own control metadata (
Package/Version/Architecture— the samefields reprepro uses), restoring the
~. This only reads metadata andrenames; package bytes are untouched, and it's a no-op for GA releases
(no
~).Testing
Verified end-to-end in a
debian:bookwormcontainer:.rc1download restored to canonical~rc1name~copy + renamed download) collapsesto one file →
reprepro includedebsucceeds, no collisionNote: only affects pre-releases (rc/beta/etc.); GA releases were never impacted. No repo cleanup needed — the fix makes the next push's names match the existing pooled ~ names.