Serve the Chocolatey icon from a CDN, pinned to the release tag - #178
Merged
Conversation
`iconUrl` was `<repo>/raw/master/bean.png`. Chocolatey's moderation treats `github.com/<owner>/<repo>/raw/...` exactly as `raw.githubusercontent.com`, and neither counts as a CDN, so the 0.5.0 submission could not be approved. The branch was the second fault, and nothing had reported it: an icon on `master` follows whatever that branch does next, under a package that is already approved and out of reach. The address now comes from `ICON_URL`, built from the same repository and tag that already produce the download URL, so the version is still typed in one place. Measured before changing anything, because a CDN address is a claim about someone else's server: jsDelivr answers 200, image/png, 21155 bytes - the same count the github.com address returns, so this moves the address and not the picture. WinGet manifests carry no icon field and are untouched. Guard: `test_packaging.py::test_the_chocolatey_icon_is_a_pinned_cdn_url` refuses both faults - the host and the missing tag - plus an entry in `MUTATIONS`. The mutation was run rather than assumed: 5 of 5 packaging mutations caught. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
The Chocolatey package's
iconUrlwas<repo>/raw/master/bean.png, and that address isrefused by moderation:
github.com/<owner>/<repo>/raw/...is treated exactly asraw.githubusercontent.com, and neither counts as a CDN. It held the 0.5.0 submission back.The branch was the second fault in the same line, and nothing had reported it. An icon
pinned to
masterfollows whatever that branch does next, under a package that is alreadyapproved and out of reach - so the fix pins to the tag as well as moving to a CDN.
The address is now
ICON_URLintools/build_packages.py, built from the same repositoryand tag that already produce the download URL, so the version is still typed in exactly one
place. The renderer's existing two-way placeholder test is half the pin: an unused entry and
an unknown placeholder both fail.
Measured before the change, because a CDN address is a claim about someone else's server:
jsDelivr answers
200,image/png,21155bytes - the same count the github.com addressreturns, so this moves the address and not the picture. Every URL in the rendered manifests
was then re-checked and all of them answer 200. WinGet manifests carry no icon field at all
and are untouched.
Guard:
test_packaging.py::test_the_chocolatey_icon_is_a_pinned_cdn_urlrefuses both faultsMUTATIONS. The mutation was runrather than written: 5 of 5 packaging mutations caught, this one by its own test.
🤖 Generated with Claude Code