Setup

Production setup

CI is the only supported way to produce a signed setup. Dispatch Build setup and choose the driver tag whose attested artifacts should be embedded. Do not build or sign the MSI locally.

Versioning

• Driver tags stay vMAJOR.MINOR.PATCH and produce MSI product version MAJOR.MINOR.PATCH.
• The first setup tag for that payload is setup-vMAJOR.MINOR.PATCH. Later setup-only re-spins (installer fixes, without rebuilding drivers) use setup-vMAJOR.MINOR.PATCH-r1, -r2, and so on.
• The MSI product version stays MAJOR.MINOR.PATCH across re-spins.
• The workflow creates the Git tag on the setup source commit (the branch or SHA you dispatched from). That can differ from the driver build commit.
• After the setup tag exists, CI opens a draft GitHub Release on that tag, attaches the signed MSI, and fills in the notes. Review the draft, smoke-test the MSI, then publish it. CI never alters an already-published release.

How to run

1. Finish a tagged Build and Partner Center signing so bthps3-tools, release-metadata, and bthps3-microsoft-drivers exist.

2. Actions → Build setup → Run workflow. Set driver-tag to vMAJOR.MINOR.PATCH (example: v2.12.0).

3. The workflow embeds that tag's signed drivers and tools, then builds the setup from the dispatched ref.

4. On success it uploads artifact bthps3-setup, creates the reserved setup-v* tag, opens a draft GitHub Release with the signed MSI, then mirrors the artifact. A tag collision fails the run without mirroring.

5. Review the draft notes, smoke-test the MSI, then publish the GitHub Release. If the draft job failed, create the release by hand from the artifact:

   gh release create setup-v3.2.0 `
     --title "BthPS3 Bluetooth Drivers v3.2.0" `
     --notes-file path\to\notes.md `
     .\Nefarius_BthPS3_Drivers_x64_arm64_v3.2.0.msi

Outputs

• Actions artifact bthps3-setup (signed MSI plus setup-metadata.json)
• Build-mirror copy of the same artifact
• Git tag setup-vMAJOR.MINOR.PATCH or setup-vMAJOR.MINOR.PATCH-rN
• Draft GitHub Release on that tag (signed MSI plus generated notes)

setup-metadata.json records the driver tag, setup tag, driver and setup commits, source run IDs, and the MSI SHA-256.

Repository configuration

Tagged driver builds and setup signing need:

• SIGN_RELAY_SERVER (variable)
• SIGN_RELAY_CI_TOKEN (secret)
• WEBHOOK_URL (secret; buildbot artifact mirror)
• SDCM_PROFILES__DEFAULT__TENANTID (secret; Partner Center)
• SDCM_PROFILES__DEFAULT__CLIENTID (secret; Partner Center)
• SDCM_PROFILES__DEFAULT__KEY (secret; Partner Center)

Draft release notes also require GitHub Copilot CLI billed to the organization so the setup workflow can use GITHUB_TOKEN with copilot-requests: write.

The setup workflow grants contents: write to the tag job and the draft-release job. The draft-release job also needs copilot-requests: write so Highlights can be generated with the GitHub Copilot CLI (GITHUB_TOKEN). The organization must allow Copilot CLI billed to the organization; otherwise that job fails and the MSI/tag still remain for a manual release.

Rerunning the draft-release job updates an existing draft and replaces its MSI. It refuses to change a release that has already been published.

Do not re-sign Microsoft-attested .sys files. Attestation adds the Microsoft signature; appending another publisher signature is incorrect.