Include token in release workflow

[swethasukumarr]

No description provided.

[Copilot]

🟡 Changes recommended

The updated release workflow introduces a few concrete risks/regressions (missing concurrency guard, weakened branch allowlist strictness, and reduced CHANGELOG validation) that should be addressed before relying on it for production releases.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates the manual GitHub Actions release workflow to use a dedicated token for checkout/tag/release operations and adds workflow inputs to drive stable vs RC tagging based on an explicit “previous release” tag. It also updates the CHANGELOG to reflect the correct SpeechSynthesis subscription API name.

Changes:

• Extend release.yml with previous_release / create_rc inputs and new logic to compute stable, RC, and RC→stable promotion tags.
• Switch checkout and gh operations to use secrets.SEMANTIC_RELEASE_TOKEN and adjust release creation flags for RCs.
• Update CHANGELOG.md API entry from subscribeVoiceChanged to subscribeOnVoicesChanged.

File summaries

File	Description
CHANGELOG.md	Fixes the documented SpeechSynthesis subscription API name.
.github/workflows/release.yml	Adds token usage and reworks release/tag computation and GitHub release publishing flow (including RC handling).

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

The workflow hard-requires secrets.SEMANTIC_RELEASE_TOKEN (no fallback) and requests broader token permissions than it appears to use, which can cause avoidable runtime failures and increases privilege unnecessarily.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

Previously missed (1) — in code that hasn't changed since the last review.

.github/workflows/release.yml:35

• The job requests issues: write and pull-requests: write, but the workflow doesn’t appear to call any APIs that need these scopes (it only uses git + gh release). Dropping unnecessary permissions reduces blast radius if the token is ever misused.

.github/workflows/release.yml:175

• GH_TOKEN is sourced exclusively from secrets.SEMANTIC_RELEASE_TOKEN. If that secret isn’t configured, the gh api calls will fail even though github.token could work (given contents: write). Consider the same PAT-or-GITHUB_TOKEN fallback here.

        env:
          TAG: ${{ steps.version.outputs.next }}
          GH_TOKEN: ${{ secrets.SEMANTIC_RELEASE_TOKEN }}
        shell: bash

.github/workflows/release.yml:208

• gh release is authenticated only via secrets.SEMANTIC_RELEASE_TOKEN. If the secret is missing, the release step will fail even though github.token is sufficient for creating/releases when contents: write is granted. Consider falling back to github.token here as well.

        env:
          GH_TOKEN: ${{ secrets.SEMANTIC_RELEASE_TOKEN }}
          TAG: ${{ steps.version.outputs.next }}
          IS_RC: ${{ steps.version.outputs.is_rc }}
          ARCHIVE: ${{ steps.asset.outputs.archive }}

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

The workflow can proceed after detecting an existing tag and potentially upload new assets to a pre-existing release tag that doesn’t point at the current HEAD, risking accidental release corruption.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The RC-to-stable “promotion” path can publish the stable tag from a different commit than the RC being promoted, which can create inconsistent releases for the same version.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

.github/workflows/release.yml:35

• The workflow grants issues: write and pull-requests: write, but the steps shown only create tags and releases via gh release/gh api, which should only require contents: write. Reducing permissions avoids unnecessary privilege in the release job.
  .github/workflows/release.yml:143
• When promoting an existing RC tag to stable (IS_PROMOTION=true), the workflow currently allows HEAD to be a descendant of the RC tag. That would publish a stable vX.Y.Z tag at a different commit than the RC being promoted, which can produce inconsistent releases for the same version. Promotion should require HEAD to match the RC tag commit exactly.

.github/workflows/release.yml:27

• The job-level if: allows any branch ending with .x-maintenance, but the in-workflow validation step (and other workflows like .github/workflows/native_full_build.yml:27) only allow *.*.x-maintenance. This mismatch can cause the workflow to start on disallowed branches and then fail during validation; consider making the job if: consistent and letting the Bash validation enforce the exact pattern.

    if: github.ref_type == 'branch' && (github.ref_name == 'main' || endsWith(github.ref_name, '.rc') || endsWith(github.ref_name, '.x-maintenance'))

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite