chore: gate marketplace publish behind PR approval check (Zoo-Code-Org#516)

* feat(zoo): gating marketplace publish behind PR approvals

* docs(release): updating process to match ci

Author: edelauna

.github/workflows/marketplace-publish.yml

@@ -7,7 +7,51 @@ on:
   workflow_dispatch:
 
 jobs:
+  check-pr-approval:
+    runs-on: ubuntu-latest
+    permissions:
+      pull-requests: read
+    steps:
+      - name: Check PR approval status
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          REPO: ${{ github.repository }}
+          SHA: ${{ github.sha }}
+        run: |
+          pr_number=$(gh api "repos/${REPO}/commits/${SHA}/pulls" \
+            --header "Accept: application/vnd.github+json" \
+            --jq '.[0].number // empty')
+
+          if [ -z "$pr_number" ]; then
+            echo "No PR found for commit ${SHA}. Deployment requires an approved PR."
+            exit 1
+          fi
+
+          review_decision=$(gh api graphql \
+            -f owner="${REPO%%/*}" \
+            -f name="${REPO#*/}" \
+            -F number="$pr_number" \
+            -f query='
+              query($owner: String!, $name: String!, $number: Int!) {
+                repository(owner: $owner, name: $name) {
+                  pullRequest(number: $number) {
+                    reviewDecision
+                  }
+                }
+              }' \
+            --jq '.data.repository.pullRequest.reviewDecision // "NONE"')
+
+          echo "PR #${pr_number} review_decision: ${review_decision}"
+
+          if [ "$review_decision" != "APPROVED" ]; then
+            echo "PR #${pr_number} is not approved (state: ${review_decision}). Deployment blocked."
+            exit 1
+          fi
+
+          echo "PR #${pr_number} is approved. Proceeding."
+
   publish-stable:
+    needs: [check-pr-approval]
     runs-on: ubuntu-latest
     environment: marketplace-production
     permissions:

.roo/commands/release.md

@@ -82,32 +82,31 @@ mode: code
     - If the release includes translated README or package-localization updates, include those files in the same PR.
     - Let the release validation workflow and normal PR checks run before merge.
 
-11. After the release PR is merged, stop for a release review on the resulting `main` commit.
+11. Once the release PR is open and passing checks, get it approved by a reviewer before proceeding.
 
-    ```bash
-    git switch main
-    git pull origin main
-    REVIEWED_SHA=$(git rev-parse HEAD)
-    git rev-parse --short "$REVIEWED_SHA"
-    ```
-
-    - Review the merged release state before any publish step.
-    - Confirm that `src/package.json`, `CHANGELOG.md`, `src/CHANGELOG.md`, and the Marketplace-facing `README.md` all reflect the intended release.
-    - Check that the release PR checks passed and that the merged commit is the one you want to ship.
-    - Share that review summary, including `REVIEWED_SHA`, with the user and wait for explicit confirmation before creating the tag.
-    - Do not create the tag or trigger publishing until the user says to proceed.
+    - Do not create the tag until the PR has at least one approval — the publish workflow enforces this automatically and will fail if no approved PR is found for the tagged commit.
 
-12. Only after explicit confirmation, create the release tag on that reviewed `main` commit:
+12. After the PR is approved, create the release tag on the release branch tip and push it:
 
     ```bash
-    git tag v[version] "$REVIEWED_SHA"
+    git tag v[version]
     git push origin v[version]
     ```
 
-    - If `main` advances after the review pause, keep using the pinned `REVIEWED_SHA` for the tag instead of silently tagging a newer commit.
+    - Tag the branch tip as-is. Do not rebase or merge additional commits into the release branch before tagging — doing so changes the commit SHA and may pull in unreviewed changes that weren't part of the approval.
+    - The publish workflow validates that the tag version matches `src/package.json`.
 
-13. The stable publish workflow runs from the `v[version]` tag.
+13. The tag push triggers the stable publish workflow.
 
-    - Do not create the tag before the release PR is merged.
-    - The publish workflow validates that the tag version matches `src/package.json`.
-    - Marketplace and Open VSX publishing use the configured CI secrets.
+    - The workflow first checks that the tagged commit belongs to an approved PR. If the PR is not yet approved this step fails — approve the PR first, then retrigger by recreating and pushing the tag: `git tag -d v[version] && git push origin :refs/tags/v[version] && git tag v[version] && git push origin v[version]`.
+    - Once the approval check passes, the `marketplace-production` environment gate fires and notifies the configured approvers.
+    - A human approver must then approve the deployment before the extension is published to VS Code Marketplace and Open VSX.
+
+14. After a successful deployment, add the release PR to the merge queue.
+
+    ```bash
+    gh pr merge [pr-number] --auto --squash
+    ```
+
+    - Do not merge before the deployment succeeds — merging first and then discovering a publish failure leaves `main` ahead of what was actually shipped.
+    - The merge queue runs all required checks against the release branch before merging to `main`.