fix: Package-and-Upload workflow attaches binaries to UI-created releases - #459
Open
jacalata wants to merge 1 commit into
Open
fix: Package-and-Upload workflow attaches binaries to UI-created releases#459jacalata wants to merge 1 commit into
jacalata wants to merge 1 commit into
Conversation
…ases
Two bugs found while investigating why v2.0.21 shipped without
executables attached:
1. The "Upload binaries to release" step was gated on
`github.event_name == 'push' && startsWith(github.ref, 'refs/tags/')`.
Releases created via the GitHub UI create a tag but do not fire the
push:tags: event that this workflow depends on, so v2.0.21 (and v2.0.19)
ended up as releases with no assets. The only successful run for
v2.0.21 was a workflow_dispatch afterward that built the binaries as
artifacts but skipped the upload-to-release step.
2. Both macOS build jobs used `name: tabcmd-macos` on
`actions/upload-artifact`, so the two same-named artifacts collided in
the artifact store and downloads clobbered each other.
Fixes:
- New `release_tag` workflow_dispatch input. Set it when dispatching from
a branch to attach binaries to a UI-created release. Falls back to
`github.ref_name` when the workflow runs on a tag ref (push or dispatch).
- Fix mac artifact collision: use `matrix.UPLOAD_FILE_NAME` (unique per
platform) as the artifact name instead of `tabcmd-${{ matrix.TARGET }}`.
- Split the upload into a separate `upload_to_release` job that depends on
`buildexe`, gated on `environment: release`. The `release` environment
needs to be created in the repo's Settings -> Environments with
required-reviewer protection (mirroring the existing `pypi` environment).
Anyone with dispatch access can trigger a build, but only an approved
reviewer can attach binaries to a public release.
- Upload gate: `if: startsWith(github.ref, 'refs/tags/') || inputs.release_tag != ''`
so both the push:tags path and the workflow_dispatch path work.
Live-verified by using `gh release upload` today to fix v2.0.21
retroactively with the artifacts from the last workflow_dispatch run.
Co-Authored-By: Claude Opus 4.7 (1M context) <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
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.
Motivation
Investigating why the v2.0.21 release page shipped with no executables attached, we found two bugs in the Package-and-Upload workflow. v2.0.19 had the same failure mode for the same reason.
Behavior change
Before: the "Upload binaries to release" step was gated on
Releases created via the GitHub UI create a tag but don't fire the
push:tags:event that this workflow depends on. So the workflow only ran manually viaworkflow_dispatchafterward, built the binaries as workflow artifacts, and skipped the upload-to-release step because theif:guard requirespush. The binaries were sitting in the artifact store for 90 days, never on the release.Separately, both macOS build jobs used
name: tabcmd-macosonactions/upload-artifact, so the two same-named artifacts collided in the artifact store andgh run downloadclobbered one with the other.After:
release_tagworkflow_dispatchinput. Set it when dispatching from a branch to attach binaries to a UI-created release. Falls back togithub.ref_namewhen the workflow runs on a tag ref (push or dispatch).matrix.UPLOAD_FILE_NAME(unique per platform) is now the artifact name instead oftabcmd-${{ matrix.TARGET }}.upload_to_releasejob that depends onbuildexe, gated onenvironment: release. Anyone with dispatch access can trigger a build, but only an approved reviewer can attach binaries to a public release. Mirrors the existingpypienvironment gate on this repo (PR security: add environment gate to production PyPI publish job #439).Prerequisite before merging
The
releaseenvironment already exists in this repo's Settings -> Environments with required-reviewer protection. Confirm it's still configured before merging; if it isn't, theupload_to_releasejob will run unguarded.Test plan
gh release upload v2.0.21 ...(with the artifacts downloaded from the last workflow_dispatch run) that the platform binaries were the right ones and could be attached to v2.0.21. The v2.0.21 release page now shows all four assets, retroactively fixed.release_taginput; confirm the approval gate fires and the four binaries end up on the release page.code-revieweragent — no blocking findings; added inline comments for theupload-artifact@v7/download-artifact@v8major mismatch (both are current best; upload@v8 doesn't exist yet) and theneeds: buildexeall-matrix-legs-must-succeed semantics.🤖 Generated with Claude Code