Stop deleting GitHub releases - #95
Merged
Merged
Conversation
A retention step deleted every older patch release within a minor so only the newest survived. Package registries pin the release asset URL for their own version and keep approved versions forever, so this broke installs permanently. The approved Chocolatey package rackstack 1.99.0 downloads .../releases/download/v1.99.0/RackStack.exe via Get-ChocolateyWebFile. Retention deleted that release when v1.99.1 shipped on 2026-05-21, so `choco install rackstack` has returned 404 for roughly two months. It cannot be repaired: no archived EXE exists and ps2exe is not reproducible, so the published checksum can never be satisfied again. The remedy is getting a current version approved. The same step also broke moderation in progress - v1.122.2 failed automated validation with "unable to find a package" because v1.122.3 published while v1.122.2 was still queued, deleting the release out from under the reviewer. dist/winget/README.md already documented the hazard for winget, filed as a temporary annoyance rather than the permanent breakage it turned out to be. Release assets on a public repo do not count against the Actions artifact storage quota, so nothing was being saved by deleting them. - Remove the retention step, with the incidents recorded inline so it is not re-added as a cleanup - Add Run-Tests section 206, failing the suite if any workflow calls `gh release delete` or `--cleanup-tag`. Verified by appending a deletion line to ci.yml and confirming the suite goes red. - Rewrite the winget README section to describe the permanent hazard
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
TheAbider
added a commit
that referenced
this pull request
Aug 13, 2026
Antivirus false-positive clearances are granted per hash. The v1.122.4 clearance on 2026-08-12 covers exactly that binary, so every release starts over with the machine-learning models no matter how small the change. That obligation was living in a checklist, which is the same place the previous one lived when it got missed. The release job now writes the new SHA-256, the portal link, and the priority caveat into the run summary, so it appears where the release is already being validated instead of depending on recall. Section 209 pins the step: it exists, links the portal, publishes the hash, writes to the summary, and carries the same version-bump gate as the build steps it follows. Also adds the winget manifests for 1.122.4. The first submission was withdrawn in July because CI retention deleted the previous release and killed the manifest's InstallerUrl between versions; that retention step was removed in #95, so the URL now stays alive. Manifests pass winget validate and the installer URL returns 200. One encoding trap fixed while writing the tests. ci.yml has no BOM, and Windows PowerShell 5.1 decodes BOM-less files as ANSI, so its em-dashes arrive as mojibake while pwsh 7 reads them correctly. The suite runs both ways -- directly under pwsh, and under powershell.exe via Validate-Release -- so an assertion matching non-ASCII text in that file passed one host and failed the other. Section 209 now reads ci.yml as UTF-8 explicitly and anchors only on ASCII. Verified green under both hosts. Structural tests 5485 -> 5493.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
choco install rackstackhas been broken for two monthsChocolatey's only approved version is
1.99.0. Pulling the actual published nupkg shows it downloads the binary rather than embedding it:That release was deleted by the retention step when v1.99.1 shipped on 2026-05-21. The URL returns 404, so every
choco install rackstackhas failed since.This particular version is unrecoverable. No archived EXE exists and ps2exe is not reproducible, so the published checksum can never be satisfied again. The only remedy is getting a current version approved, which is in moderation now.
Why the retention rule was wrong
Package registries pin the release asset URL for their own version and keep approved versions indefinitely. Deleting a release breaks those installs permanently.
It also broke moderation in progress. The v1.122.2 Chocolatey submission failed automated validation with "We were unable to find a package, and are unable to continue validation" — because v1.122.3 published while v1.122.2 was still queued, and retention deleted the release out from under the reviewer.
dist/winget/README.mdalready described this hazard, but filed it as a temporary annoyance ("installs recover as soon as the update PR merges"). For Chocolatey it was a permanent outage.There was no storage argument either: release assets on a public repo do not count against the Actions artifact storage quota. If disk hygiene ever matters, prune Actions artifacts — never releases.
Changes
ci.yml, replaced by a comment recording both incidents so it is not re-added as a well-meaning cleanup.Run-Testssection 206 fails the suite if any workflow callsgh release deleteor contains--cleanup-tag. Verified by appending a deletion line toci.ymland confirming the suite goes red, then restoring the file byte-identically.dist/winget/README.mdsection to describe the permanent hazard and point at the guard.Verification
Follow-up outside this PR
The approved
rackstack 1.99.0on community.chocolatey.org will keep failing until a newer version is approved. v1.122.3 has passed install/uninstall verification and is flagged only for VirusTotal detections, pending a moderator exemption request.