Skip to content

ci: attach the portable archive the updater actually requires - #13

Merged
StaticHumStudio merged 1 commit into
mainfrom
ci/attach-portable-archive-to-release
Aug 8, 2026
Merged

ci: attach the portable archive the updater actually requires#13
StaticHumStudio merged 1 commit into
mainfrom
ci/attach-portable-archive-to-release

Conversation

@StaticHumStudio

Copy link
Copy Markdown
Owner

Found while preparing v2.0.2. Blocking that release.

The gap

windows-installation-behavior already builds the exact portable zip and its SHA256 sidecar with scripts/build-release.ps1, and runs the tamper-rejection test against those bytes. Then it throws both away. The release job only ever attached the installer .exe, so HumWatch-vX.Y.Z.zip and .zip.sha256 have been uploaded to every release by hand.

That is not a cosmetic omission. scripts/update-core.ps1 resolves both by exact name on the latest release:

if ($zipMatches.Count -ne 1 -or $digestMatches.Count -ne 1) { throw 'The named release or its SHA256 manifest is missing' }

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-behavior gains a portable_artifact output and uploads the zip plus sidecar (if-no-files-found: error).
  • release downloads it into the same staging directory as the installer and attaches all three in one gh 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:

behavior outputs: {'portable_artifact': '${{ steps.portable.outputs.name }}'}
release needs: ['build', 'windows-service-security', 'windows-service-security-installed', 'windows-installation-behavior', 'linux-security']
release steps: ['Download validated installer artifact', 'Download validated portable archive', 'Attach to release']

241 passed, 5 skipped. The real proof is the v2.0.2 tag build, which is what this unblocks.

🤖 Generated with Claude Code

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>

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

@StaticHumStudio
StaticHumStudio merged commit bd2e63f into main Aug 8, 2026
7 checks passed
@StaticHumStudio
StaticHumStudio deleted the ci/attach-portable-archive-to-release branch August 8, 2026 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant