Skip to content

Cutting a release

Official releases are cut by CI: push a v<semver> tag and the signed-release workflow builds, signs, and attaches the installers to a draft GitHub Release. A local script covers quick unsigned dev builds.

IntuneCommander is a single public repository — adamgell/IntuneCommander — holding the source, these docs, and the published binaries on its Releases page (the release channel).

The Signed Release (MSI + MSIX) workflow is the source of truth. It runs on a version tag and produces a signed MSI, a signed MSIX, and a portable zip for both arm64 and x64.

  1. Match the version. Set [package] version in app/Cargo.toml to the release version (no leading v). CI fails fast if the tag and Cargo.toml disagree.

  2. Tag and push.

    Terminal window
    git tag v1.0.0-beta.1
    git push origin v1.0.0-beta.1

    Or run it manually from Actions → Signed Release → Run workflow with a version — the workflow creates the tag for you.

  3. CI builds and signs. For each architecture it builds the Rust/WinUI client, publishes the self-contained .NET sidecar, bundles the pinned Maester modules, then packages a signed MSI + MSIX with Master Packager Dev (Azure Trusted Signing) plus a portable zip. Build provenance is attested.

  4. Publish the draft. CI attaches every asset to a draft GitHub Release — a -beta.N tag is auto-marked prerelease. Review it and hit Publish.

For a quick local build without CI or signing, scripts/release.ps1 (PowerShell 7+) builds the client + self-contained sidecar and stages a runnable, zipped bundle per architecture. Use -DryRun to keep the artifacts local — they land in .\dist and nothing is published:

Terminal window
# both arches, unsigned, artifacts only (no GitHub release):
.\scripts\release.ps1 -Version 1.0.0-beta.1 -DryRun

These builds are unsigned — use them for testing, not distribution. Signed, published releases always go through the CI workflow above.