fix: enforce existing Git tag guard in electron release workflow

[mahata]

The Electron release workflow validated only GitHub Release existence, not raw Git tag existence. This could allow dispatching a version whose electron-v{version} tag already exists without a release object.

• Validation hardening

  • Updated the validate step to check both:
    • existing Git tag
    • existing GitHub Release
  • Step is now explicitly named to reflect both checks.

• Tag existence check implementation

  • Added a direct remote tag check via git ls-remote --tags against refs/tags/electron-v${VERSION}.
  • Retained release existence check with gh release view as a separate guard.

TAG_NAME="electron-v${VERSION}"
if git ls-remote --exit-code --tags "https://github.com/${GITHUB_REPOSITORY}.git" "refs/tags/${TAG_NAME}" > /dev/null 2>&1; then
  echo "Tag ${TAG_NAME} already exists"
  exit 1
fi

[Copilot]

Pull request overview

Adds a manual GitHub Actions workflow to build and publish Electron desktop releases across macOS/Windows/Linux, producing a GitHub Release with attached artifacts.

Changes:

• Introduces .github/workflows/electron-release.yml with workflow_dispatch + version input.
• Adds validate → matrix build → release job pipeline, including artifact upload/download.
• Automates GitHub Release creation under tag electron-v{version} with generated notes.

Show a summary per file

File	Description
.github/workflows/electron-release.yml	New workflow to validate a version, build Electron installers per-OS, and create a GitHub Release with artifacts.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 3

[Copilot]

The "Check tag does not already exist" step is checking for an existing release via gh release view, but it does not actually verify whether the Git tag electron-v${VERSION} already exists (a tag can exist without a release). This conflicts with the PR description and can allow reusing an existing tag unintentionally; consider checking tag existence explicitly (e.g., git ls-remote --tags or gh api /repos/{owner}/{repo}/git/ref/tags/...) in addition to or instead of the release check.

[mahata]

@copilot apply changes based on this feedback

[Copilot]

Implemented in 9e9882d. The validate job now checks tag existence explicitly with git ls-remote --tags ... refs/tags/electron-v${VERSION} before release creation, and still blocks if a release with that tag already exists.

[Copilot]

npm version is run before actions/setup-node pins the Node.js version from .node-version. This means the workflow may use whatever Node/npm happens to be preinstalled on the runner for that step, which can change over time and reduce reproducibility. Move the version-update step after setup-node (and ideally after corepack enable), or use pnpm -C electron pkg set version=... after Node is set up.

[mahata]

@copilot apply changes based on this feedback

Let's move the version-update step after setup-node.

[Copilot]

The version regex currently accepts values like 1.0.0.alpha (dot-separated prerelease), but npm version (used later) expects SemVer and will reject some strings that this regex allows. This can cause the workflow to pass validation but fail during the build step; consider tightening the regex to align with SemVer (and with what npm version accepts), or validate by invoking the same SemVer parser used by npm.

[mahata]

@copilot apply changes based on this feedback