Create initial GitHub Actions CI/CD and WinGet submission

[sirredbeard]

No description provided.

[Copilot]

Pull request overview

This PR introduces the initial CI/CD pipeline for the CopilotTaskbarApp project using GitHub Actions. It adds three workflows: a build workflow triggered on pull requests and reusable for releases, a release workflow to orchestrate the full build/tag/publish flow, and a WinGet submission workflow to automate publishing to the Windows Package Manager repository.

Changes:

• Added .github/workflows/build.yml: Reusable build workflow that compiles and packages the app for x64 and ARM64, conditionally producing ZIP artifacts when a version input is provided.
• Added .github/workflows/release.yml: Orchestration workflow (triggered via workflow_dispatch) that calls build.yml, creates a git tag, creates a GitHub Release with assets, and calls winget-release.yml for WinGet submission.
• Added .github/workflows/winget-release.yml: Reusable workflow that downloads release assets, computes SHA256 hashes, generates WinGet manifests, and submits them using wingetcreate.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
.github/workflows/build.yml	Build + artifact upload workflow triggered by PRs and reusable for release
.github/workflows/release.yml	Release orchestration: tag creation, GitHub Release creation, and WinGet submission
.github/workflows/winget-release.yml	WinGet manifest generation and submission to the public winget-pkgs repo

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The outputs block on the release job (lines 23–24) declares tag: v${{ inputs.version }}, but this output is never referenced by any downstream job. The winget job uses v${{ inputs.version }} directly rather than needs.release.outputs.tag. This dead code adds confusion about whether the output is meant to be used and should be removed.

Suggested change

	outputs:
	tag: v${{ inputs.version }}

[Copilot]

The wingetcreate binary is downloaded from the unversioned, un-pinned redirect https://aka.ms/wingetcreate/latest, and no integrity check (e.g., SHA256 verification) is performed on the downloaded binary. This means: (1) any future change to that binary could silently break the workflow or, in a worst-case supply-chain compromise scenario, execute arbitrary code; (2) builds are not reproducible since the binary version can change at any time. Consider downloading a specific versioned release from the official GitHub Releases page (e.g., https://github.com/microsoft/winget-create/releases/download/vX.Y.Z/wingetcreate.exe) and verifying its SHA256 hash before executing it.

Suggested change

	Invoke-WebRequest "https://aka.ms/wingetcreate/latest" -OutFile wingetcreate.exe
	$wingetCreateVersion = "v1.5.5" # TODO: update to desired pinned version
	$expectedHash = "EXPECTED_SHA256_HERE" # TODO: replace with SHA256 of wingetcreate.exe for the pinned version
	$wingetCreateUrl = "https://github.com/microsoft/winget-create/releases/download/$wingetCreateVersion/wingetcreate.exe"
	Invoke-WebRequest $wingetCreateUrl -OutFile wingetcreate.exe
	$actualHash = (Get-FileHash "wingetcreate.exe" -Algorithm SHA256).Hash.ToLowerInvariant()
	if ($actualHash -ne $expectedHash.ToLowerInvariant()) {
	Write-Error "SHA256 hash mismatch for wingetcreate.exe. Expected $expectedHash but got $actualHash."
	exit 1
	}

[Copilot]

The $dir argument passed to wingetcreate.exe is unquoted. While the version value is controlled via workflow inputs, quoting the path argument (e.g., .\wingetcreate.exe submit --token "${{ secrets.WINGET_PAT }}" "$dir") is a best practice to guard against unexpected behavior if the path were to contain spaces or special characters in the future.

Suggested change

	.\wingetcreate.exe submit --token "${{ secrets.WINGET_PAT }}" $dir
	.\wingetcreate.exe submit --token "${{ secrets.WINGET_PAT }}" "$dir"

[Copilot]

The winget-release.yml workflow is triggered both by the release event (lines 3–5) and as a reusable workflow called from release.yml. Since release.yml creates a GitHub Release (which fires the released event), the WinGet submission will be triggered twice: once via workflow_call from release.yml, and once by the release event trigger in winget-release.yml itself. This will cause duplicate (and likely failing) WinGet submissions. Consider removing the release event trigger from winget-release.yml and relying solely on the workflow_call from release.yml, or alternatively remove the workflow_call from release.yml and keep only the release event trigger.

Suggested change

	release:
	types: [released]