ci: call the APT publish from release.yml instead of trusting on: release - #71
Merged
Conversation
…lease`
`apt-repo.yml` was triggered by `on: release: [published]`, which never fired
for a tagged release. `release.yml` publishes with ${{ github.token }}, and
GitHub deliberately raises no workflow-triggering event for anything a
GITHUB_TOKEN did — a recursion guard. So the index was only ever rebuilt when
somebody remembered to dispatch it by hand.
It had run exactly once in its first month. 1.4.16, 1.4.17, 1.4.23 and 1.4.25
were all published while the APT index sat unchanged, so `apt upgrade` users
were pinned to whatever was current on 2026-07-01. Nothing failed loudly; the
release workflow went green every time.
`apt-repo.yml` now also accepts `workflow_call`, and release.yml invokes it as a
job after the .dmg upload (transitively after the .deb, so the release exists
with its artifact before the index is collected). A direct call needs no event
delivery, so it cannot silently skip.
`secrets: inherit` because the publish signs with APT_GPG_PRIVATE_KEY.
Kept `release: published` for releases a human or PAT publishes through the UI —
those do raise the event, and release.yml never sees them — and kept
`workflow_dispatch` for backfills. The repo is rebuilt from every release .deb
each run, so overlapping entry points are idempotent, and the existing
concurrency group serialises them.
Not verifiable before the fact: only a real tag push exercises the new path. If
the call is wrong the release still succeeds and the index goes stale exactly as
it does today, with the manual dispatch as the fallback.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This was referenced Jul 31, 2026
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.
Problem
apt-repo.ymlwas triggered byon: release: [published]. That never fired for a tagged release:release.ymlpublishes with${{ github.token }}, and GitHub deliberately raises no workflow-triggering event for anything aGITHUB_TOKENdid (a recursion guard). So the index was only ever rebuilt when someone remembered to dispatch it manually.It had run exactly once in its first month:
Meanwhile 1.4.16, 1.4.17, 1.4.23 and 1.4.25 all shipped while the APT index sat unchanged —
apt upgradeusers were pinned to whatever was current on 1 July. Nothing failed loudly; the release workflow went green every time. The backlog only cleared because a later manual dispatch rebuilds from all release.debs.Change
apt-repo.ymlalso acceptsworkflow_call.release.ymlinvokes it as a job after the.dmgupload — transitively afterdeb(macos already needs it), so the release exists with its artifact attached before the index is collected.Being called needs no event delivery, so it can't silently skip.
Why the other triggers stay
release: publishedstill covers releases a human or PAT publishes through the UI — those do raise the event, andrelease.ymlnever sees them.workflow_dispatchstays for backfills. The repo is rebuilt from every release.debon each run, so overlapping entry points are idempotent, and the existingconcurrency: group: apt-reposerialises them.Verification
YAML parses and the call job is structurally valid (no
runs-on/steps,secrets: inheritpresent,needsresolves).Only a real tag push exercises the new path —
release.ymlis tag-triggered, so there's no dry run short of cutting a release. If the wiring is wrong the release still succeeds and the index goes stale exactly as it does today, withgh workflow run apt-repo.ymlas the fallback. Worth watching the Actions tab on the next tag for anaptjob in the release run.