Add release workflow for Linux and Windows

[hangzqcom]

This PR adds a GitHub Actions release workflow and a Windows build script to automate the release process for both Linux and Windows drivers.

Changes

.github/workflows/release.yml

A workflow_dispatch workflow triggered manually from the GitHub Actions UI. It accepts:

Input	Description	Example
linux_version	Linux driver version to release	1.0.6.5
windows_version	Windows driver version to release	1.00.94.6
base_branch	Branch to cut the release from	main (default)
release_notes	Markdown release notes	(auto-generated if empty)
draft	Create as draft release	false (default)

Either or both versions can be supplied in a single run.

Linux job (fully automated on GitHub-hosted runner):

1. Creates release branch release-lnx-{version}
2. Updates src/linux/version.h with the new version
3. Commits and pushes the release branch
4. Builds the .deb package via src/linux/build-deb.sh
5. Packages the .deb + RELEASES.md + README.md into a zip
6. Creates annotated tag release-lnx-v{version}
7. Publishes the GitHub release with the zip as an artifact

If the build fails:

• The workflow run turns red in the Actions tab and GitHub sends an email notification to the person who triggered it
• A Job Summary is written to the workflow run page showing which step failed and the last 50 lines of the build log
• The summary also shows the release branch name and instructs the user to delete it before re-running

Windows job (branch/tag/release automation only — build is local):

1. Creates release branch release-win-{version}
2. Updates src/windows/qcversion.h with the new version
3. Commits and pushes the release branch
4. Creates annotated tag release-win-v{version}
5. Opens a draft GitHub release (signed build artifacts must be attached before publishing)

build/build_drivers.ps1

PowerShell build script for Windows drivers (requires Visual Studio + WDK on the build machine):

• Auto-detects MSBuild via vswhere and WDK via registry
• Builds filter, ndis, qdss, and wdfserial driver projects for x86, x64, and arm64
• Stamps INF file versions from src/windows/qcversion.h
• Generates catalog files via inf2cat
• Packages output to build/target/Drivers/Windows10/

Release naming convention

Platform	Branch	Tag
Linux	release-lnx-{version}	release-lnx-v{version}
Windows	release-win-{version}	release-win-v{version}

Access control — only maintainers can trigger a release

The workflow enforces two independent gates:

Gate 1 — Explicit permission check (in-workflow)
The first step of the validate job calls the GitHub API to verify the triggering actor has write, maintain, or admin permission on the repository. If not, the workflow fails immediately with a clear error message before any branch or tag is created.

Gate 2 — Environment protection (environment: release)
Both release jobs use environment: release. When configured in Settings → Environments with required reviewers, the workflow pauses for explicit human approval even after the permission check passes.

To configure the environment (repo admin, one-time setup):

1. Go to Settings → Environments → New environment, name it release
2. Enable Required reviewers → add the maintainer team
3. Optionally enable Prevent self-review

If the release environment does not exist, Gate 1 (permission check) still enforces maintainer-only access.

How to trigger a release

1. Go to Actions → Release → Run workflow
2. Fill in the version(s) and click Run workflow

For Linux-only release:

• linux_version: 1.0.6.7
• windows_version: (leave empty)

For Windows-only release:

• linux_version: (leave empty)
• windows_version: 1.00.94.7

Example: Linux release 1.0.6.5

Triggered via workflow dispatch with linux_version=1.0.6.5:

1. Workflow created branch release-lnx-1.0.6.5 and updated src/linux/version.h
2. Built qud_1.0.6.5_all.deb via build-deb.sh on a GitHub-hosted Ubuntu runner
3. Created tag release-lnx-v1.0.6.5
4. Published release with artifact qud_1.0.6.5_all.zip

Result: https://github.com/qualcomm/qcom-usb-kernel-drivers/releases/tag/release-lnx-v1.0.6.5

Example: Windows release 1.00.94.6

Step 1 — Trigger workflow with windows_version=1.00.94.6:

• Workflow created branch release-win-1.00.94.6 and updated src/windows/qcversion.h
• Created tag release-win-v1.00.94.6
• Opened a draft GitHub release

Step 2 — Build locally on a Windows machine with Visual Studio 2019 + WDK:

git clone https://github.com/qualcomm/qcom-usb-kernel-drivers.git
git checkout release-win-1.00.94.6
.\build\build_drivers.ps1

Step 3 — Upload and publish:

# Zip the build output
Compress-Archive build\target\Drivers\Windows10 qud_1.00.94.6_windows.zip

# Upload to the draft release and publish
gh release upload release-win-v1.00.94.6 qud_1.00.94.6_windows.zip --repo qualcomm/qcom-usb-kernel-drivers
gh release edit release-win-v1.00.94.6 --draft=false --repo qualcomm/qcom-usb-kernel-drivers

Result: https://github.com/qualcomm/qcom-usb-kernel-drivers/releases/tag/release-win-v1.00.94.6

Notes on Windows driver signing

The build script produces test-signed drivers (WDK auto-generates a WDKTestCert per machine). For production distribution, drivers must be submitted to Microsoft Hardware Dev Center for attestation signing using an EV code-signing certificate. The build/build_drivers.ps1 script includes a Sign-File helper that can be extended to support production signing.

Test results

The complete workflow was tested on fork hangzqcom/qcom-usb-kernel-drivers after all changes were applied.

Linux release 1.0.6.6 — workflow run

Job / Step	Result
Validate inputs	✅
→ Check actor is a maintainer	✅
→ Check version format	✅
Linux release 1.0.6.6 — Create release branch	✅
Linux release 1.0.6.6 — Update src/linux/version.h	✅
Linux release 1.0.6.6 — Build deb package	✅
Linux release 1.0.6.6 — Job summary	✅
Linux release 1.0.6.6 — Create release zip	✅
Linux release 1.0.6.6 — Create and push tag	✅
Linux release 1.0.6.6 — Create GitHub release	✅
Windows release	⏭️ skipped (not requested)

Published release: https://github.com/hangzqcom/qcom-usb-kernel-drivers/releases/tag/release-lnx-v1.0.6.6
Artifact: qud_1.0.6.6_all.zip

Windows release 1.00.94.6 — tested previously

Step	Result
Workflow: create branch + tag + draft release	✅
Local build (build_drivers.ps1)	✅
Upload artifact + publish release	✅

Published release: https://github.com/hangzqcom/qcom-usb-kernel-drivers/releases/tag/release-win-v1.00.94.6

Security

All ${{ inputs.* }} and ${{ steps.*.outputs.* }} interpolations have been moved out of run: blocks into per-step env: sections to prevent shell injection (Semgrep run-shell-injection rule).

[5656hcx]

Looks good, if already tested we can merge and see how it works for future releases.

One thing is this action will not update sub versions of individual drivers like QCOM_ADB_VERSION. Can we handle it through GitHub actions? Or do we want to keep individual version number for each drivers in the future?