Rework release process with workflow_dispatch

[kevingosse]

• Change release.yml trigger from tag push to workflow_dispatch with version input
• Add version validation (x.y.z format, must be greater than latest release)
• Auto-update version in ClipPing.rc (UTF-16 LE), commit, tag, and push
• Extract winget submission into separate publish-winget.yml workflow

[Copilot]

Pull request overview

This PR reworks the GitHub Actions release pipeline to be manually triggered with an explicit version input, then automates version bumping/tagging and separates WinGet publishing into its own workflow.

Changes:

• Switch release.yml from tag-push trigger to workflow_dispatch with a version input and basic version validation.
• Auto-update src/ClipPing/ClipPing.rc version fields (UTF-16 LE), then commit, tag, and push before building and publishing the GitHub Release.
• Move WinGet submission into a new manually-triggered workflow (publish-winget.yml) that targets the latest GitHub Release.

Reviewed changes

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

File	Description
.github/workflows/release.yml	Manual release trigger with version validation, RC version bump + commit/tag/push, then build + GitHub Release creation.
.github/workflows/publish-winget.yml	New manual workflow to submit/update the WinGet package based on the latest GitHub Release tag.

---

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

[Copilot]

Version validation only compares against the latest release (via gh release view) and does not check whether the tag v${{ inputs.version }} already exists. If this workflow is re-run after a partial failure (e.g., tag was pushed but the GitHub Release wasn’t created), validation may pass but git tag/git push will fail later. Consider also checking remote tags (e.g., git ls-remote --tags origin v$version) and failing early with a clear error if the tag already exists.

Suggested change

	tag_name="v$version"
	if git ls-remote --tags origin "refs/tags/$tag_name" | grep -q "refs/tags/$tag_name"; then
	echo "::error::Git tag '$tag_name' already exists in remote 'origin'. Choose a different version or delete the existing tag."
	exit 1
	fi

[Copilot]

git commit -m ... will fail the workflow if the RC update produced no diff (or if the workflow is re-run after the version bump commit already exists). It’s safer to either (1) check git diff --quiet and exit with a helpful error before committing, or (2) make the commit step conditional so the workflow is idempotent and produces a clear failure mode.

Suggested change

	- name: Commit and tag
	run: |
	git config user.name "github-actions[bot]"
	git config user.email "github-actions[bot]@users.noreply.github.com"
	git add src/ClipPing/ClipPing.rc
	- name: Commit and tag
	shell: bash
	run: |
	git config user.name "github-actions[bot]"
	git config user.email "github-actions[bot]@users.noreply.github.com"
	git add src/ClipPing/ClipPing.rc
	# If there are no staged changes, skip commit, tag, and push to keep the workflow idempotent.
	if git diff --cached --quiet; then
	echo "No changes to commit; skipping commit, tag, and push."
	exit 0
	fi

[Copilot]

gh release view is called without any error handling. If the repository has no releases yet (or the API call fails transiently), this step will error and the workflow will stop without a clear message. Consider adding explicit handling (e.g., fallback/::error:: message) so it’s obvious why winget publishing can’t proceed.

Suggested change

	tag=$(gh release view --json tagName --jq '.tagName')
	echo "tag=$tag" >> "$GITHUB_OUTPUT"
	set -euo pipefail
	if ! tag=$(gh release view --json tagName --jq '.tagName' 2>/dev/null); then
	echo "::error::Failed to get latest release via 'gh release view'. Ensure at least one GitHub release exists and that the GitHub CLI can access the repository."
	exit 1
	fi
	if [ -z "${tag}" ] || [ "${tag}" = "null" ]; then
	echo "::error::'gh release view' returned no tagName. Ensure at least one GitHub release exists before running this workflow."
	exit 1
	fi
	echo "tag=${tag}" >> "$GITHUB_OUTPUT"

[Copilot]

Because workflow_dispatch can be run against any branch/ref, this workflow can currently create a release/tag from a non-default branch if someone triggers it from the wrong ref. To avoid accidental releases, consider validating github.ref (e.g., require refs/heads/master) early in the workflow and failing with a clear error if it’s not the intended release branch.