[jacalata]

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

if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags/')

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 via workflow_dispatch afterward, built the binaries as workflow artifacts, and skipped the upload-to-release step because the if: guard requires push. The binaries were sitting in the artifact store for 90 days, never on the release.

Separately, both macOS build jobs used name: tabcmd-macos on actions/upload-artifact, so the two same-named artifacts collided in the artifact store and gh run download clobbered one with the other.

After:

• 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 dispatched at a tag ref.
• Mac artifact collision fixed: matrix.UPLOAD_FILE_NAME (unique per platform) is now the artifact name instead of tabcmd-${{ matrix.TARGET }}.
• Upload logic split into a new upload_to_release job that depends on buildexe, gated on environment: release. Anyone with dispatch access can trigger a build, but only an approved reviewer can attach binaries to a public release. Mirrors the existing pypi environment gate on this repo (PR security: add environment gate to production PyPI publish job #439).
• release-on-merge.yml no longer dispatches package.yml. Merging to main only pushes the tag and creates the draft release; publishing it starts the build. The merge-time run targeted a draft, which upload-release-action can't find by tag, and every release needed two release approvals.

Prerequisite before merging

The release environment already exists in this repo's Settings -> Environments with required-reviewer protection. Confirm it's still configured before merging; if it isn't, the upload_to_release job will run unguarded.

Test plan

• Live-verified today via 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.
• End-to-end verification after merge: for v2.0.22 or a test tag, publish the draft release that the merge creates, or dispatch with --ref <tag> for an already-published release; confirm the approval gate fires and the four binaries end up on the release page.
• Code review from code-reviewer agent — no blocking findings; added inline comments for the download-artifact@v7 choice (it versions independently of upload-artifact@v7 and reads its artifacts) and the needs: buildexe all-matrix-legs-must-succeed semantics.

🤖 Generated with Claude Code

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
tabcmd
__main__.py	12	12	12	0%
_version.py	11	11	11	0%
tabcmd.py	15	15	15	0%
version.py	10	6	6	40%
tabcmd/commands
commands.py	10	10	10	0%
constants.py	77	18	18	77%
server.py	135	18	18	87%
tabcmd/commands/auth
session.py	394	50	50	87%
tabcmd/commands/datasources_and_workbooks
datasources_and_workbooks_command.py	157	18	18	89%
datasources_workbooks_views_url_parser.py	142	5	5	96%
delete_command.py	70	23	23	67%
export_command.py	120	25	25	79%
get_url_command.py	127	47	47	63%
publish_command.py	134	16	16	88%
runschedule_command.py	21	7	7	67%
tabcmd/commands/extracts
create_extracts_command.py	42	8	8	81%
decrypt_extracts_command.py	27	2	2	93%
delete_extracts_command.py	37	6	6	84%
encrypt_extracts_command.py	27	2	2	93%
extracts.py	20	2	2	90%
reencrypt_extracts_command.py	27	2	2	93%
refresh_extracts_command.py	48	10	10	79%
tabcmd/commands/group
create_group_command.py	29	5	5	83%
delete_group_command.py	27	2	2	93%
tabcmd/commands/project
create_project_command.py	46	8	8	83%
delete_project_command.py	35	4	4	89%
publish_samples_command.py	30	4	4	87%
tabcmd/commands/site
create_site_command.py	34	5	5	85%
delete_site_command.py	27	2	2	93%
edit_site_command.py	66	18	18	73%
list_command.py	77	12	12	84%
list_sites_command.py	29	2	2	93%
tabcmd/commands/user
add_users_command.py	29	5	5	83%
create_site_users.py	58	11	11	81%
create_users_command.py	59	9	9	85%
delete_site_users_command.py	43	5	5	88%
user_data.py	222	31	31	86%
tabcmd/execution
_version.py	2	2	2	0%
global_options.py	147	8	8	95%
localize.py	67	11	11	84%
logger_config.py	60	6	6	90%
tabcmd_controller.py	42	7	7	83%
TOTAL	2946	470	84%

[Copilot]

🟡 Changes recommended

Restore compatible dispatch behavior and resolve the release tag across all supported workflow paths.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the packaging workflow to build platform binaries and upload them to releases through a reviewer-gated job.

Changes:

• Adds unique artifact names to prevent macOS collisions.
• Separates release uploads into a gated job.
• Updates release-trigger and artifact-upload handling.

Review findings:

• Moderate (3 votes): Removing workflow_dispatch breaks the existing release-on-merge caller and manual repair path.
• Moderate (1 vote): Hard-coded github.event.release.tag_name is empty for dispatch and tag-ref workflows.

File summaries

File	Description
.github/workflows/package.yml	Updates workflow triggers, artifact naming, and release uploads.

Review details

Suppressed comments (1)

.github/workflows/package.yml:142

• The upload job hard-codes github.event.release.tag_name, which is populated for the release event but not for the workflow-dispatch or tag-ref paths described in the PR. In those paths the upload action receives an empty target tag and cannot attach the artifacts to the release. Resolve a validated target tag from the dispatch input, release payload, or tag ref and reuse it for all uploads (and the concurrency group).

        tag: ${{ github.event.release.tag_name }}

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

The workflow lacks the described release_tag workflow_dispatch input and currently resolves tags in a way that can mis-target uploads or unnecessarily block on environment approval for branch-dispatched runs.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2

Open (2)

• Add release_tag input for branch-based dispatches · New
• Include release_tag in concurrency grouping · New

Resolved since last review (1)

• The workflow_dispatch trigger was removed, but .github/workflows/release-on-merge.yml:67 still…

[Copilot]

Copilot review overview

🟡 Changes recommended

The workflow_dispatch path is missing the documented/expected release_tag input (and tag resolution can target the wrong tag when dispatched from a branch), and the new documentation incorrectly states the PyPI gate uses the release environment.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2 · 1

Open (3)

• Include release_tag in concurrency grouping
• Add release_tag input for branch-based dispatches
• Correct documented PyPI environment approval gate · New

[Copilot]

🔵 Needs a closer look

Unresolved workflow trigger, artifact-upload sequencing, and contradictory documentation issues remain.

No open issues 🎉

3 previously missed issues

In code that hasn't changed since last review

Restore the workflow's tag push trigger

.github/​workflows/​package.yml:17

The workflow no longer has a push trigger, so pushing a tag cannot start this workflow at all. That makes the documented/declared github.ref_name fallback for a tag push unreachable and contradicts the test plan's “either push a tag” path. Retain the tag push trigger (the existing GITHUB_TOKEN tag push from release-on-merge will still be covered by the explicit dispatch), or remove the push path from the comments and release instructions.

Use download-artifact v8 for v7 uploads

.github/​workflows/​package.yml:139

This job uploads artifacts with actions/upload-artifact@v7, but the corresponding current download action is actions/download-artifact@v8 (the upload action has no v8 release). Pinning the downloader to v7 leaves this new upload path on the wrong major and can prevent the job from resolving/downloading the build artifacts; use the v8 downloader here.

Remove or update the conflicting manual release procedure

contributing.md:198

This new procedure leaves the ## Release process section immediately below unchanged, where it still tells maintainers to create releases manually and copy artifacts from Actions. That directly contradicts the merge/publish flow and reviewer-gated automatic attachment documented here, so following this file can still lead to manual uploads; update or remove that legacy procedure as part of this change.

3 resolved since last review

• Include release_tag in concurrency grouping
• Add release_tag input for branch-based dispatches
• Correct documented PyPI environment approval gate

_{Review effort: Lite}

[Copilot]

🟡 Changes recommended

Critical security issues remain around build-job token permissions and the ability to modify the workflow before dispatch.

2 open issues

• Prevent branch dispatch from bypassing release approval · New
• Restrict build job GITHUB_TOKEN permissions · New

_{Review effort: Lite}