Skip to content

ci(test-build): pack an unsigned .intunewin + add correlation run-name#133

Open
raysubham wants to merge 3 commits into
step-security:mainfrom
raysubham:feat/test-build-intunewin
Open

ci(test-build): pack an unsigned .intunewin + add correlation run-name#133
raysubham wants to merge 3 commits into
step-security:mainfrom
raysubham:feat/test-build-intunewin

Conversation

@raysubham
Copy link
Copy Markdown
Contributor

Why

test-build.yml builds MSIs only (artifacts windows-msis, windows-exes, linux, darwin). The integration-test Intune MSI E2E is gaining a commit mode so we can validate the real Win32 Intune delivery path against an arbitrary commit before tagging a release — but that needs a .intunewin, and today only release.yml produces one (IntuneWinAppUtil runs on a Windows runner; the ubuntu Go harness can't pack it).

What

In the existing build-msi (windows) job, after the MSIs are built:

  • Download IntuneWinAppUtil.exe — same commit-pinned raw URL + canonical SHA-256 as release.yml, then an Authenticode check (Microsoft Corporation, Status=Valid).
  • Pack .intunewin (x64 + arm64) — mirrors release.yml exactly: install.cmd as the -s setup entry point, with uninstall.cmd and the MSI staged in the source folder; renamed to stepsecurity-dev-machine-guard-<version>-<arch>.intunewin.
  • Upload as a new windows-intunewin artifact.

No Sigstore signing, no release upload, no attestation — this is an unsigned snapshot for pre-tag validation only. Packaging and filename are otherwise byte-identical to a release, so the downstream Intune pipeline is unchanged.

Also adds an optional correlation_id input echoed into run-name, so a dispatcher (the E2E) can bind to the exact run it triggered — a workflow_dispatch run's head_sha is the ref HEAD, not commit_id, so the SHA alone can't identify it, and a newest-run heuristic could bind to a concurrent dispatch.

Safety / blast radius

  • Purely additive (94 lines): no change to existing artifacts, the build job, or the PR-comment flow. correlation_id is optional — existing callers are unaffected, and an empty value just leaves a trailing space in run-name.
  • Tool is pinned by commit SHA and SHA-256 and Authenticode-verified, same posture as release.yml.
  • permissions: unchanged (contents: read on the job).

Companion / validation

  • Consumed by integration-test PR step-security/integration-test#884 (commit mode downloads windows-intunewin and matches the run by the correlation_id marker). Merge this first so that PR's commit mode can run.
  • .github/workflows/test-build.yml parses as valid YAML; the added steps are a faithful copy of the proven release.yml pack. Will confirm end-to-end by dispatching this workflow for a recent commit and checking the windows-intunewin artifact before the E2E uses it.

test-build.yml built MSIs only. The integration-test Intune MSI E2E needs a
per-commit .intunewin to validate the real Win32 delivery path BEFORE a release
is tagged, and only release.yml could produce one (IntuneWinAppUtil runs on a
Windows runner).

This adds, in the existing windows build-msi job, a pack step mirroring
release.yml -- pinned + Authenticode-verified IntuneWinAppUtil, install.cmd as
the setup entry point with uninstall.cmd and the MSI staged alongside -- and
uploads the result as the windows-intunewin artifact. No Sigstore signing or
release upload: this is an unsigned snapshot for pre-tag validation only;
packaging and filename are otherwise byte-identical to a release.

Also adds an optional correlation_id input echoed into run-name, so a dispatcher
(the integration-test E2E) can bind to the exact run it triggered -- a
workflow_dispatch run's head_sha is the ref HEAD, not commit_id, so the SHA alone
cannot identify it.

No change to existing artifacts (windows-msis/-exes/linux/darwin) or the
PR-comment flow.
@raysubham raysubham force-pushed the feat/test-build-intunewin branch from 7db61d5 to bbbe7cb Compare June 8, 2026 06:41
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.

2 participants