ci: attach the portable archive the updater actually requires - #13
Conversation
The portable installation job already builds the exact zip and SHA256 sidecar the updater expects, runs the tamper-rejection test against them, and then threw both away. Every release since has had them attached by hand. update-core.ps1 resolves HumWatch-vX.Y.Z.zip and its .sha256 by exact name on the latest release and throws when either is missing. So a forgotten upload does not degrade the updater, it disables it on every portable install pointed at that release. That is a worse outcome than the bug #12 just fixed, and it was one distracted release away at any moment. The release job now attaches the same bytes the tamper test just validated, alongside the installer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3e1c1795e5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| $tag = "${{ inputs.release_tag }}" | ||
| if (-not $tag) { $tag = "${{ github.ref_name }}" } | ||
| gh release upload $tag $installer.FullName --clobber | ||
| gh release upload $tag $installer.FullName $portable.FullName $sidecar.FullName --clobber |
There was a problem hiding this comment.
Reject portable archives whose version differs from the target tag
When a manual dispatch supplies a release_tag that differs from the checked-out agent.__version__, this command uploads the build-version archive to the independently selected release—for example, HumWatch-v2.0.1.zip to v2.0.2. The checked gh release upload <tag> <files>... interface accepts arbitrary asset names, while scripts/update-core.ps1 looks only for HumWatch-v2.0.2.zip and its exact sidecar, so the workflow succeeds but leaves portable updating disabled for that release. Validate that the archive version equals $tag.Substring(1) before uploading, or build/name the archive from the target tag.
Useful? React with 👍 / 👎.
Found while preparing v2.0.2. Blocking that release.
The gap
windows-installation-behavioralready builds the exact portable zip and its SHA256 sidecar withscripts/build-release.ps1, and runs the tamper-rejection test against those bytes. Then it throws both away. Thereleasejob only ever attached the installer.exe, soHumWatch-vX.Y.Z.zipand.zip.sha256have been uploaded to every release by hand.That is not a cosmetic omission.
scripts/update-core.ps1resolves both by exact name on the latest release:So one forgotten upload does not degrade the updater. It disables it on every portable install pointed at that release, and there is no fallback path. That is a worse failure than the one #12 just fixed, and it was one distracted release away at any time.
The change
windows-installation-behaviorgains aportable_artifactoutput and uploads the zip plus sidecar (if-no-files-found: error).releasedownloads it into the same staging directory as the installer and attaches all three in onegh release upload, with an explicit check for each.The attached bytes are now the same ones the tamper test validated, rather than whatever was built by hand on a workstation afterward.
Verification
Workflow parses and the wiring resolves:
241 passed, 5 skipped. The real proof is the v2.0.2 tag build, which is what this unblocks.🤖 Generated with Claude Code