From edffa71b6e90f5bdbf9847c4bf5857cc060fb09d Mon Sep 17 00:00:00 2001 From: Andy Jordan <2226434+andyleejordan@users.noreply.github.com> Date: Mon, 18 May 2026 11:15:45 -0700 Subject: [PATCH] Restructure release skill into ordered phases with verification gates - Group the 12 steps into 5 phases (Prep, GitHub PRs, ADO mirror, Signed pipelines, Publish) so the dependency chain is explicit - Verify the release commit landed (`git log -1 --format=%s`) before pushing to ADO, and wait for ADO PR `status=completed` before queuing pipelines -- phase 4 builds against `refs/heads/main` and would silently produce the wrong version if either gate were skipped - Split phase 4 into separate steps for PSES and vscode-powershell so the agent can notify me when each pipeline hits its manual approval stage - Drop the old "publishing the tag triggers marketplace" line: the vscode-powershell pipeline pushes to marketplace directly after approval, only the GitHub drafts need a manual publish - Use `gh release edit --repo / --generate-notes` to populate draft release bodies - Reference `release infrastructure` and `release maintainers` memory entries so private contacts stay out of the repo - Drop redundant rationale where the command itself already encodes the fix Drafted by Copilot (Claude Opus 4.7). --- .github/skills/release/SKILL.md | 96 +++++++++++++++++++++++++++++---- 1 file changed, 85 insertions(+), 11 deletions(-) diff --git a/.github/skills/release/SKILL.md b/.github/skills/release/SKILL.md index 856cf48fbb..61e39a2a94 100644 --- a/.github/skills/release/SKILL.md +++ b/.github/skills/release/SKILL.md @@ -7,19 +7,93 @@ description: > # Release Process -Read [docs/development.md](../../../docs/development.md) "Creating a Release" and "Versioning" sections first. +Read [docs/development.md](../../../docs/development.md) "Creating a Release" and "Versioning" +first — this skill only adds the agent-specific deltas. -## Agent-Actionable Steps (1–2) +Memory entries this skill depends on (load before starting): -1. Use `./tools/updateVersion.ps1 -Version "" -Changes ""` in both repos - (PSES first, then vscode-powershell). The script validates even/odd rules, updates - `package.json` version, prepends a changelog entry (auto-including the PSES version from - `../PowerShellEditorServices`), and creates a commit. -2. Push to an ephemeral `release` branch and open a PR to `main` on GitHub. +- **`release infrastructure`** — ADO org, project, and pipeline IDs. +- **`release maintainers`** — the GitHub PR reviewer and the ADO release approver (two + different people). -## Manual Steps (3–4) +PSES leads the extension at every step: its module is embedded in the signed extension +build, so its release must land before the corresponding vscode-powershell action. -These require Azure DevOps access and cannot be performed by an agent: +## Phase 1 — Prep -3. After merge, push `main` to the Azure DevOps remote (`ado HEAD:upstream`) to trigger signing pipelines. -4. Download and test assets from draft GitHub Releases, then publish. +1. **Sync `main`** in both `../PowerShellEditorServices` and `vscode-powershell`: + `git checkout main && git pull --ff-only origin main`. +2. **Propose version + summary.** In each repo run + `git log --oneline $(git describe --tags --abbrev=0)..HEAD`, summarize user-visible + changes, apply the rules from docs/development.md "Versioning", and confirm both + versions and one-line summaries with the user before continuing. + +## Phase 2 — GitHub release PRs + +3. **Run `updateVersion.ps1`** in PSES first, then vscode-powershell: + + ```sh + git checkout -B release + pwsh -NoProfile -c '$env:GIT_EDITOR="true"; ./tools/updateVersion.ps1 -Version "" -Changes ""' + ``` + +4. **Push and open PRs.** `git push origin release`, then open a PR to `main` via the + GitHub MCP `create_pull_request` tool. Title is the commit subject + (`v: `). DM the GitHub PR reviewer on Teams with both PR links. +5. **Enable auto-squash-merge** on both PRs: + `gh pr merge --repo / --squash --auto`. +6. **Wait for both PRs to merge** (`gh pr view ... --json state,statusCheckRollup`). + Don't busy-loop — check, report, pause if it'll be a while. + +## Phase 3 — Mirror to ADO + +7. **Sync `main` and push to ADO `upstream`** in both repos (PSES first). The verify + step must print the release commit subject (`v: `); if it doesn't, + the PR hasn't merged yet — stop and wait. + + ```sh + git checkout main && git pull --ff-only origin main + git log -1 --format=%s + git push ado HEAD:upstream + ``` + +8. **Open `upstream → main` PRs in ADO** with auto-complete enabled. The current `ado` + MCP server doesn't reach our org, so use `az` (org/project from memory). Title is + always `Integrate upstream changes`. Use **merge commit** (preserves GitHub history) + and keep the `upstream` branch (re-pushed every release): + + ```sh + az repos pr create --org --project --repository \ + --source-branch upstream --target-branch main \ + --title "Integrate upstream changes" --description "Integrate v from GitHub upstream." + az repos pr update --org --id \ + --auto-complete true --squash false --delete-source-branch false + ``` + + DM the ADO release approver on Teams with both ADO PR links. + +9. **Wait for both ADO PRs to complete** + (`az repos pr show --org --id --query status` returns `completed`). + Auto-complete merges them once policy checks pass; phase 4 builds against + `refs/heads/main` and will produce the wrong version if main hasn't been updated yet. + +## Phase 4 — Signed pipelines + +Each pipeline pauses at a manual approval stage before publishing. Notify the user +when each one reaches it. Use a detached watcher (`az pipelines runs show --id +`) so polling survives across turns. + +10. **Queue the PSES pipeline** on `refs/heads/main` with template parameters + `Release=True OfficialBuild=True`. Notify the user when it reaches the approval + stage, then wait for `result == succeeded`. On success the pipeline creates a + draft GitHub Release in PSES. +11. **Queue the vscode-powershell pipeline** the same way. Notify the user at its + approval stage. On success the pipeline creates a draft GitHub Release in + vscode-powershell _and_ publishes the extension to the VS Code marketplace. + +## Phase 5 — Publish GitHub releases (manual) + +12. For each draft GitHub Release (PSES and vscode-powershell), populate the body via + `gh release edit v --repo / --generate-notes`. Send the user + links to both drafts for review; they publish them manually. The marketplace push + already happened in step 11.