Skip to content

Stop deleting GitHub releases - #95

Merged
TheAbider merged 1 commit into
masterfrom
fix/stop-deleting-releases
Jul 30, 2026
Merged

Stop deleting GitHub releases#95
TheAbider merged 1 commit into
masterfrom
fix/stop-deleting-releases

Conversation

@TheAbider

Copy link
Copy Markdown
Owner

choco install rackstack has been broken for two months

Chocolatey's only approved version is 1.99.0. Pulling the actual published nupkg shows it downloads the binary rather than embedding it:

url64bit   = 'https://github.com/TheAbider/RackStack/releases/download/v1.99.0/RackStack.exe'
checksum64 = 'a3daf09975a1617c5ab576295e008982f2ac34d1441a4699ca423b536731bf44'
Get-ChocolateyWebFile @packageArgs

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 rackstack has 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.md already 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

  • Remove the retention step from ci.yml, replaced by a comment recording both incidents so it is not re-added as a well-meaning cleanup.
  • Run-Tests section 206 fails the suite if any workflow calls gh release delete or contains --cleanup-tag. Verified by appending a deletion line to ci.yml and confirming the suite goes red, then restoring the file byte-identically.
  • Rewrite the dist/winget/README.md section to describe the permanent hazard and point at the guard.

Verification

  • 5428/5428 structural tests pass, 0 failures, 0 skipped (+2 from section 206)
  • No version bump — this is CI and documentation only, so merging does not cut a release. That matters right now: with retention gone, the next release will no longer disturb v1.122.3 while it sits in Chocolatey moderation.

Follow-up outside this PR

The approved rackstack 1.99.0 on 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.

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

codecov Bot commented Jul 30, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@TheAbider
TheAbider merged commit c681b75 into master Jul 30, 2026
7 checks passed
@TheAbider
TheAbider deleted the fix/stop-deleting-releases branch July 30, 2026 04:45
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant