feat(ci): reusable Velopack release workflow for Windows desktop apps #5

2026-10-09T19:35:18Z

KofTwentyTwo commented

2026-10-09 19:35:18 +00:00

(Migrated from github.com)

What

.github/workflows/release-velopack.yml (reusable): the release pipeline of the Windows reference architecture, built in KofTwentyTwo/standards so provenance names it as the builder (SLSA Build L3, K22-CI-30).
- build (Windows, read-only): strict SemVer tag → channel dev (prerelease) or stable; re-runs the gates (locked restore, -warnaserror Release build, tests, coverage gate; K22-CI-31); publishes the app unpackaged + self-contained (WindowsPackageType=None, WindowsAppSDKSelfContained=true, no trimming) and an optional single-file CLI.
- package (Windows, release environment): optional Azure Trusted Signing over OIDC (azure/login + azure/artifact-signing-action) before vpk pack, and vpk pack --azureTrustedSignFile so Setup.exe is signed too. sign defaults to false (exception EX-0002). Delta baseline via vpk download github (continue-on-error on a channel's first release). Keeps only this build's assets from assets.<channel>.json, with releases.<channel>.json trimmed to them, which is how vpk upload builds its feed. CLI zipped as <app-id>-cli-<runtime>-<version>.zip.
- sbom (Linux): CycloneDX 1.6 of the published app and CLI (pinned Syft), attested against Setup.exe, portable zip, full package, CLI zip.
- attest (Linux): SHA256SUMS over every asset (including the fixed-name Setup/portable/feed files, K22-REL-03), provenance for all.
- release (Linux): draft with all assets + generated notes, then publish (immutable releases).
templates/workflows/release-velopack.yml: caller, plus an optional winget job (stable only, WINGET_TOKEN in the caller's release environment, wingetcreate v1.12.13.0 pinned by URL + SHA-256).
Docs: K22-CI-30 names the workflow; standards/releases.md (assets table, signing, winget); README workflow table; the reference architecture's pipeline section now describes exactly what runs.

Why

The Windows app template (and gclo's migration) needs a shared, attested release path; this replaces gclo's in-repo release.yml.

How tested

actionlint clean; zizmor --offline default and pedantic: no findings on the reusable workflow (the template's only finding is its {{STANDARDS_SHA}} placeholder, same as the other templates); markdownlint-cli2 0.23.3: 0 issues; gitleaks clean.
Not yet run in Actions; the first real run will be the Windows app template's first tag (see below).

Not verifiable without a real tag run

vpk CLI flags (--outputDir, --azureTrustedSignFile) and the asset/feed layout come from the Velopack 1.2.161 sources; the trimmed releases.<channel>.json mirrors vpk upload's feed but has not been read back by an installed app yet.
Whether vars.* in the reusable workflow resolve from the caller's release environment (needed only when sign: true).
Whether vpk pack re-signs binaries already signed by the signing action (harmless either way).
Syft SBOM depth for a self-contained WinUI publish folder.

Generated with Claude Code

## What - **`.github/workflows/release-velopack.yml`** (reusable): the release pipeline of the Windows reference architecture, built in KofTwentyTwo/standards so provenance names it as the builder (SLSA Build L3, K22-CI-30). - **build** (Windows, read-only): strict SemVer tag → channel `dev` (prerelease) or `stable`; re-runs the gates (locked restore, `-warnaserror` Release build, tests, coverage gate; K22-CI-31); publishes the app unpackaged + self-contained (`WindowsPackageType=None`, `WindowsAppSDKSelfContained=true`, no trimming) and an optional single-file CLI. - **package** (Windows, `release` environment): optional Azure Trusted Signing over OIDC (`azure/login` + `azure/artifact-signing-action`) **before** `vpk pack`, and `vpk pack --azureTrustedSignFile` so Setup.exe is signed too. `sign` defaults to false (exception EX-0002). Delta baseline via `vpk download github` (continue-on-error on a channel's first release). Keeps only this build's assets from `assets.<channel>.json`, with `releases.<channel>.json` trimmed to them, which is how `vpk upload` builds its feed. CLI zipped as `<app-id>-cli-<runtime>-<version>.zip`. - **sbom** (Linux): CycloneDX 1.6 of the published app and CLI (pinned Syft), attested against Setup.exe, portable zip, full package, CLI zip. - **attest** (Linux): `SHA256SUMS` over every asset (including the fixed-name Setup/portable/feed files, K22-REL-03), provenance for all. - **release** (Linux): draft with all assets + generated notes, then publish (immutable releases). - **`templates/workflows/release-velopack.yml`**: caller, plus an optional `winget` job (stable only, `WINGET_TOKEN` in the caller's `release` environment, `wingetcreate` v1.12.13.0 pinned by URL + SHA-256). - Docs: K22-CI-30 names the workflow; `standards/releases.md` (assets table, signing, winget); README workflow table; the reference architecture's pipeline section now describes exactly what runs. ## Why The Windows app template (and gclo's migration) needs a shared, attested release path; this replaces gclo's in-repo `release.yml`. ## How tested - actionlint clean; zizmor `--offline` default and pedantic: no findings on the reusable workflow (the template's only finding is its `{{STANDARDS_SHA}}` placeholder, same as the other templates); markdownlint-cli2 0.23.3: 0 issues; gitleaks clean. - Not yet run in Actions; the first real run will be the Windows app template's first tag (see below). ## Not verifiable without a real tag run - `vpk` CLI flags (`--outputDir`, `--azureTrustedSignFile`) and the asset/feed layout come from the Velopack 1.2.161 sources; the trimmed `releases.<channel>.json` mirrors `vpk upload`'s feed but has not been read back by an installed app yet. - Whether `vars.*` in the reusable workflow resolve from the caller's `release` environment (needed only when `sign: true`). - Whether `vpk pack` re-signs binaries already signed by the signing action (harmless either way). - Syft SBOM depth for a self-contained WinUI publish folder. Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/standards#5