Actually publish to the package managers - #114
Merged
Merged
Conversation
TronBrowser has never reached a single package manager. The channels were scaffolded on 2026-06-25 and every manifest in distribution/ still said 0.1.0 while releases went out to 3.15.0. Four separate things had to be true for a release to ship downstream and none of them were. The trigger never fired. submit-packages.yml listened on `release: [published]`, but release.yml un-drafts with GITHUB_TOKEN, and GitHub raises no workflow events for what a GITHUB_TOKEN does. The workflow has zero runs in three months. release.yml now calls it directly through workflow_call, which needs no PAT. The dry-run flag was read from `github.event.inputs.dry_run`, which is empty on anything that is not a workflow_dispatch. The guard was `!= "false"`, so a release run appended --dry-run every time: even with a working trigger the submit path could not have executed. Chocolatey was worse, hardcoded --dry-run with no way to turn it off. The refreshed manifests were thrown away with the runner. Nothing committed them, which is why the tree never moved off 0.1.0. They are now opened as a PR, since those files are the input to every channel's submission and a stale tree means even a working submit publishes the wrong version. And there was no submission code at all. The header said submission was "gated on the relevant secret", but no push, PR or upload existed anywhere in the script -- it rewrote files and exited. Channels we own outright now really publish: homebrew to our tap, scoop to our bucket, AUR over ssh (with a generated .SRCINFO, since makepkg is not on a runner), Chocolatey via choco push, Snap via snapcraft upload. The five that are a pull request into someone else's monorepo (winget, flathub, nixpkgs, gentoo, freebsd) cannot be automated end to end and now say so with a link, rather than printing success. A channel with no secret refreshes its manifest, explains the skip and exits clean, so a credential-less repo still goes green. A channel that has its secret and fails is allowed to break the build, because a silent success here is exactly what hid this for three months. Verified against the real v3.15.0 release: manifests refresh to 3.15.0 and the generated AUR sha256 matches the published tarball byte for byte. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
ThreatCrush Security Scan52 finding(s) HIGH/CRITICAL: 3 | MEDIUM: 28 | LOW: 21
…and 2 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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.
TronBrowser has never reached a single package manager. The channels were
scaffolded on 2026-06-25 and every manifest in
distribution/still said0.1.0 while releases went out to 3.15.0.
Four things had to be true for a release to ship downstream. None were.
submit-packages.ymllistened onrelease: [published], butrelease.ymlun-drafts withGITHUB_TOKEN, and GitHub raises no workflow events for what aGITHUB_TOKENdoesDRY_RUNreadgithub.event.inputs.dry_run, empty on anything but aworkflow_dispatch; the guard was!= "false"--dry-run, so even a working trigger could not submit--dry-runPlus the refreshed manifests were discarded with the runner, which is why the
tree never moved off 0.1.0.
What this does
release.ymlcalls the workflow directly viaworkflow_call. No PAT needed.inputscontext and passed explicitly; a release passesdry_run: false. Chocolatey honours the same flag..SRCINFO(makepkg is not on a runner), Chocolatey viachoco push, Snap viasnapcraft upload.A channel with no secret refreshes its manifest, explains the skip and exits
clean, so this repo (which currently has zero Actions secrets) still goes
green. A channel that has its secret and fails breaks the build — a silent
success is exactly what hid this for three months.
Verified
Ran against the real v3.15.0 release: manifests refresh to 3.15.0, and the
generated AUR
sha256sumsmatches the publishedtronbrowser-linux-x64.tar.gzbyte for byte (
0870fc5f…8779).Still needs you
Nothing publishes until the credentials exist. Secrets to add to
profullstack/tronbrowser.dev:HOMEBREW_TAP_TOKENprofullstack/homebrew-tap(repo must exist)SCOOP_BUCKET_TOKENprofullstack/scoop-bucket(repo must exist)AUR_SSH_KEYtronbrowser-binCHOCOLATEY_API_KEYSNAPCRAFT_STORE_CREDENTIALSsnapcraft export-login; also needs the release job to build and passSNAP_FILEwinget / flathub / nixpkgs / gentoo / freebsd need a one-time upstream
submission by a person before any automation is meaningful.
🤖 Generated with Claude Code