Push tag over ssh via deploy key, not the Releases API

[swethasukumarr]

No description provided.

[Copilot]

Pull request overview

This PR updates the manual release workflow to create and push the release tag via an SSH deploy key (instead of relying on the GitHub Releases API to create the tag), then creates/updates the GitHub Release object against the already-pushed tag.

Changes:

• Switch actions/checkout to use an SSH deploy key so subsequent git push uses SSH auth.
• Add an explicit “Create tag” step that creates an annotated tag and pushes it to origin.
• Update the release creation step to omit --target, since the tag is now created ahead of time.

---

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

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

.github/workflows/release.yml:148

• The promotion path (RC -> stable) assumes the workflow is running on the same commit as the RC tag, but this step tags the current checkout HEAD. If the workflow is dispatched from main (or any ref other than the RC tag), the stable tag can be created on the wrong commit. Also, if the target tag already exists on origin, skipping creation without verifying it points to HEAD can result in uploading artifacts for one commit under a release/tag pointing to another commit.

          if git ls-remote --exit-code --tags origin "refs/tags/${TAG}" >/dev/null 2>&1; then
            echo "Tag ${TAG} already exists on origin; skipping tag creation."
            exit 0
          fi

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

.github/workflows/release.yml:156

• If the tag already exists on origin, the workflow currently skips tag creation unconditionally. That can lead to publishing a release/asset built from the current HEAD against an existing tag that points to a different commit (e.g., rerunning from a newer HEAD while reusing the same version tag). Consider verifying that the existing remote tag resolves to the current HEAD, and fail if it doesn't, to avoid mismatched artifacts.

          if git ls-remote --exit-code --tags origin "refs/tags/${TAG}" >/dev/null 2>&1; then
            echo "Tag ${TAG} already exists on origin; skipping tag creation."
            exit 0
          fi