automated-release-run

# Run an Automated Release Trigger the repo's automated-release wrapper workflow (the hand-authored `.github/workflows/*.yml` file that forwards to `SonarSource/release-github-actions/.github/workflows/automated-release.yml@v1` — its filename varies per repo, see Step 1) for an analyzer repo and stay with it until every pull request it opens (version bump, SQS, SQC, SQAA) is reviewed, green, and merged, and the SONAR integration ticket's fixVersion is set — so the user can ask once and walk away instead of babysitting PRs across multiple repos and a Jira ticket. This skill assumes the target repo already has that wrapper workflow set up (see the `automated-release-setup` skill if it doesn't). **Always link, don't just name.** Whenever you mention a Jira ticket, a GitHub workflow run, or a pull request anywhere in this skill's output, include its actual URL (`https://sonarsource.atlassian.net/browse/<KEY>` for Jira, or whatever `gh`/the Atlassian MCP returns) — not just the key/number. The user should be able to click straight through without having to construct the link themselves. **Heads up on permission prompts.** This skill runs a number of read-only shell commands (`gh`, `git`, `date`, `mktemp`) to inspect repo/release state and poll status as it goes. If you'd rather not approve each one individually, pre-approve these command prefixes for the session (or project-locally in `.claude/settings.local.json`) before starting — the skill itself has no way to do this for you. ## Step 1 — Identify the repo and read its release config 1. **Check the current directory first.** If it's already a git checkout of a repo under the `SonarSource` org (`git remote get-url origin`) with a `.github/workflows/*.yml` file that forwards to `release-github-actions/.github/workflows/automated-release.yml@v1` (grep as in step 4 below — don't assume the filename), ask the user via `AskUserQuestion`: "Release `<repo>` (the one you're in)?" with that as the first/default option and "No, a different repo" as the other. Only fall through to step 2 below if the user picks the latter, or if the current directory isn't a recognizable checkout at all. 2. Otherwise, parse the repo name from the request, e.g. "Release sonar-pli" or "Release SonarSource/sonar-pli". A bare name (`sonar-pli`) is assumed to be under the `SonarSource` GitHub org; accept a full `org/repo` too. 3. Find a local checkout to read the wrapper workflow file from: - If the current directory is already a checkout of that repo (`git remote get-url origin` matches), use it directly. - Otherwise, ask the user (via `AskUserQuestion`) where it's already cloned — offer a free-text path option and a "not cloned yet" option. Don't assume any particular directory layout (e.g. `~/Projects`) — that's a personal convention, not a portable default. - If not cloned, ask where to clone it, defaulting to a fresh temp directory (`mktemp -d`) so it's disposable. A shallow `git clone` is enough — this only needs to read one YAML file, not build or test anything. 4. Read the repo's wrapper workflow file. **Don't assume it's named `automated-release.yml`** — it's hand-authored per repo (by the `automated-release-setup` skill or manually) and the filename varies (e.g. sonar-php uses `AutomateRelease.yml`). Find it by content, not name: ```bash grep -rl "release-github-actions/.github/workflows/automated-release.yml@v1" .github/workflows/ ``` Use whatever path that returns for every later step in this skill (reading inputs here, and the `gh workflow run <filename>` call in Step 5 — that command also takes the actual filename, not a hardcoded `automated-release.yml`). This file declares `workflow_dispatch` inputs and forwards them to `SonarSource/release-github-actions/.github/workflows/automated-release.yml@v1`. **Parse the actual file — don't assume a fixed input list.** Every repo customizes it (e.g. some add `ide-integration`, `dry-run`, `bump-version`; others don't). 5. From that same file, note the hardcoded `with:` values for `project-name`, `plugin-name`, `jira-project-key` — these are fixed per repo, don't ask the user for them. ## Step 2 — Releasability pre-flight Before interviewing the user, verify the target branch (default `master`, or whatever the user names in Step 3) is actually releasable. This is a fast fail before spending any time on the interview or a full workflow run. ```bash gh api "/repos/<owner>/<repo>/commits/<branch>/status" \ --jq '.statuses[] | select(.context=="Releasability")' ``` - Fail with the description shown if `.state != "success"`, or if the description contains "failed optional checks" (mirrors `check-releasability-status/action.yml`'s logic). - Also check for any other failing required checks on the branch: ```bash gh api "/repos/<owner>/<repo>/commits/<branch>/check-runs" \ --jq '.check_runs[] | select(.conclusion != "success" and .conclusion != "skipped" and .conclusion != "neutral")' ``` - If either check fails, stop — but don't just report the failure and give up. Diagnose it and help the user fix it (see "Diagnosing and fixing releasability problems" below). Do not proceed to Step 3 until releasability passes. - Tell the user this is a **pre-flight convenience check**, not the authoritative one — the workflow's own `check-releasability` job re-checks the exact commit SHA via `SonarSource/gh-action_releasability@v3` when it actually runs, so this step is about failing fast and cheaply, not replacing that gate. ### Diagnosing and fixing releasability problems Don't stop at "releasability failed" — read the `description` field closely, since it usually names the specific sub-check that failed (e.g. `"failed optional checks -> Jira"`, `"failed optional checks -> Peachee Languages Statistics"`) and diagnose each failure to a concrete, actionable cause before presenting it to the user: - **`-> Jira`**: the releasability check requires no unresolved tickets against the project's unreleased Jira version. Query for the blockers directly instead of asking the user to go look. Resolve the Jira `cloudId` (site host, e.g. `sonarsource.atlassian.net`) via `mcp__atlassian__getAccessibleAtlassianResources` if not already known, then use the Atlassian MCP (`mcp__atlassian__searchJiraIssuesUsingJql`) with something like: `project = <JIRA_PROJECT_KEY> AND fixVersion in unreleasedVersions() AND status not in (Done, Closed, Resolved, Canceled)` — adjust the "done-like" status list per project if that query returns nothing, since workflow status names vary per project. List every matching ticket with its **clickable Jira link** (`https://<site>/browse/<KEY>`), summary, status, and assignee so the user can see exactly what's outstanding without having to go look it up themselves, and check `mcp__atlassian__getTransitionsForJiraIssue` for each to see whether a direct "Close as Done" / "Cancel Issue" / similar terminal transition exists. - **`-> Quality Gate`**: a SonarQube quality gate is failing on the release branch — link the user directly to the project's SonarQube quality gate page rather than guessing at a fix; this isn't something to auto-resolve. - **`-> Dependencies` / `-> Licenses` / `-> Manifest Values` / `-> Parent POM` / `-> GitHub`**: these indicate a code/config problem (outdated parent POM, license mismatch, manifest metadata) that needs a real code change — report which one failed, with a link to the releasability check run (`target_url` on the status) so the user can see the detail, and stop; don't attempt an automated fix for these. - **Other failing check-runs** (from the check-runs API call above, not the Releasability status itself): report the check name with a link to its GitHub Actions run/job (`.html_url` on the check-run) so the user can look at the logs directly; these are usually CI/build failures needing a real fix, not a quick toggle. For each fixable issue (mainly the Jira case), **suggest the concrete fix, with a link to the ticket, and ask for confirmation before acting** — e.g. "[SONARPLI-390](<jira-link>) is 'In Validation' and blocking release; transition it to Done?" — since transitioning a ticket or touching shared state is visible to others and should not happen silently. Use `mcp__atlassian__transitionJiraIssue` once confirmed, and share the ticket's link again in the confirmation of what was done. **After every fix is applied, don't assume it's reflected immediately** — the `Releasability` commit status is stale until it's recomputed. Find the job that posted it and re-run just that job, then re-poll the status before declaring victory: ```bash # The status's target_url points at the workflow run that posted it. Find the specific # job named "Releasability Check" (or similar) inside that run: gh run view <run-id-from-target_url> --repo <owner>/<repo> --json jobs \ --jq '.jobs[] | select(.name | test("Releasability"; "i"))' # Re-run just that job (not the whole pipeline): gh run rerun <run-id> --repo <owner>/<repo> --job <job-id> # Poll until it completes, then re-fetch the Releasability status (same command as above) # and confirm the description no longer mentions the fixed issue. ``` Repeat the diagnose → fix → confirm → re-run → re-check loop until releasability actually passes (description like `"passed releasability checks"`, not just `state == "success"` with a lingering "failed optional checks" description). Only then proceed to Step 3. ## Step 3 — Interview Using `AskUserQuestion`, ask for each `workflow_dispatch` input found in Step 1, in the order they appear in the YAML: - **`AskUserQuestion` requires ≥2 options per question — it errors out otherwise.** A required free-text input with no meaningful default (e.g. `short-description` on a repo where it has no YAML default) is not a valid multi-choice question. For these, either (a) skip `AskUserQuestion` entirely and just ask in plain text, or (b) derive a concrete draft value first — e.g. from the unreleased Jira ticket(s) for this project (see the derivation pattern used for `short-description` below) — and offer that draft as one option against a "type my own" option as the second. Don't send a single-option question; it fails validation and wastes a round trip. Batch the remaining genuinely-multi-choice inputs (booleans, branch, version) into one `AskUserQuestion` call rather than a call-per-input. - If a required free-text field like `short-description` has no natural default, consider proactively querying the project's unreleased Jira backlog (`project = <jira-project-key> AND fixVersion in unreleasedVersions() ORDER BY issuetype ASC, key ASC` via `mcp__atlassian__searchJiraIssuesUsingJql`) and drafting a summary from the ticket(s) found, rather than asking the user to write one from scratch or falling back to a generic placeholder — this is the same backlog Step 3's release-notes drafting already reads, so it's not extra API surface. - Show each input's description and default value so the user can accept a default with one click instead of retyping it. - Present boolean inputs as Yes/No with the YAML default pre-selected. - For `new-version` (or equivalent): explain it is the *next* Jira version to create after this release, **not** the version being released, and that leaving it blank lets the workflow increment the last component of the current Jira version (`2.1` → `2.2`). Passing the version being released is a trap: it normalizes to the version that was just released, so `create-jira-version` finds it already exists, skips creation, and returns the just-released version as the "next" one — which the bump-version job would then write back to the branch. Wrapper repos often still describe this input as "new version to release"; ignore that wording. - If the user sets `dry-run` (or `use-jira-sandbox`/`is-draft-release`) to `false`... actually, the important warning is the opposite: **if `dry-run` is left `true` or explicitly requested**, tell the user plainly that this is not a true no-op. It only affects the Jira sandbox and whether the GitHub release is a draft — the SQS/SQC/SQAA/bump-version pull requests are still created for real either way. Don't let "dry-run" imply nothing will happen outside GitHub. - If `sqs-integration` is enabled (default `true`), also ask which SQS release this analyzer version will ship with — this sets the `fixVersion` on the SONAR/SQS integration ticket that the workflow creates later (see Step 9). Ask this now, up front, rather than after the SQS PR merges — the skill's whole point is one confirmation before triggering, then walking away; asking mid-flight would reintroduce the exact interruption it's meant to avoid. Compute a default before asking, don't ask blind: query the Jira **SONAR** project's versions (`jira_client.project_versions()` — same pattern as `get-jira-release-notes/get_jira_release_notes.py`), filter to `released == false`, sort by `releaseDate` ascending, and take the first as "next SQS release" (names follow the `sqs-YYYY.N` convention, e.g. `sqs-2026.5`). Ask via `AskUserQuestion` with that default as the first option (labelled with its name and release date, e.g. "sqs-2026.5 (2026-09-21, next release) — default") and a free-text option to name a different version — "next" is a reasonable guess but not a guarantee, a change can miss a train and ship in a later one. Store the chosen version name; nothing is written to Jira yet — see Step 9. - For `release-notes`: if the user leaves it blank (accepting auto-generation by `get-jira-release-notes`), ask via `AskUserQuestion` (Yes/No) whether they'd like a short intro paragraph drafted ahead of the auto-generated issue list. The `release-notes` input is all-or-nothing — a non-blank value fully replaces auto-generation — so this only works by building the whole value here, not by asking the workflow to prepend anything: 1. If yes, fetch the same issues `get-jira-release-notes` would (`project = <jira-project-key> AND fixVersion = "<new-version>" ORDER BY issuetype ASC, key ASC` via `mcp__atlassian__searchJiraIssuesUsingJql`), using the `issue-categories` order from that repo's `automated-release.yml` `with:` block if it overrides the default (`Feature,False Positive,False Negative,Bug,Security,Maintenance`). 2. Draft a 1-2 sentence paragraph summarizing the release's theme from those issue summaries and the `short-description` already given, and show it to the user for approval/edit — one round of confirmation, same as everywhere else in this step. 3. Reproduce `get_jira_release_notes.py`'s `format_notes_as_markdown` structure exactly (`# Release notes - {project name} - {version}` header, then `### {category}` sections in order, each issue as `[KEY](jira-url/browse/KEY) summary`), inserting the approved paragraph directly under the header line. Use this full string as the `release-notes` value passed in Step 5. 4. If the user declines, leave `release-notes` blank — unchanged, auto-generated behavior. ## Step 4 — Summary and confirmation Show a concrete table of input → value (including defaults accepted silently) and the exact `gh workflow run` command that will be executed. If `sqs-integration` is enabled, include the SQS fixVersion chosen in Step 3 as its own row (e.g. `| SQS fixVersion (SONAR ticket) | sqs-2026.5 |`), and note that it will be applied automatically to the SONAR integration ticket once that ticket exists later in the run (Step 9) — with no further prompt for it. Also state plainly what happens *after* triggering: this skill will monitor the workflow to completion, then automatically approve and merge all resulting pull requests (bump-version, SQS, SQC, SQAA) as soon as each is green — with no further prompts in between, unless something fails or needs a judgment call (see Step 8's failure handling). Ask the user to confirm this whole flow once, up front, in plain language — triggering a release is a cross-repo, hard-to-reverse action, and the point of this skill is that one confirmation here is the only interaction needed; don't ask again before merging each PR later, or before setting the fixVersion in Step 9. ## Step 5 — Trigger Use the actual filename discovered in Step 1 (e.g. `AutomateRelease.yml`), not a hardcoded `automated-release.yml` — `gh workflow run` and `gh run list --workflow` both need the real filename or they'll silently match nothing / the wrong workflow. ```bash gh workflow run <actual-filename> --repo <owner>/<repo> --ref <branch> \ -f "<input>=<value>" ... ``` Conveniently, `gh workflow run` actually does print the run URL directly to stdout on recent `gh` versions — capture and share that; don't assume you need to construct one, but do construct `https://github.com/<owner>/<repo>/actions/workflows/<actual-filename>` as a fallback if the output is empty. Then resolve the run ID the same way `publish-github-release/action.yml` does: ```bash sleep 30 RUN_ID=$(gh run list --repo <owner>/<repo> --workflow <actual-filename> --limit 1 \ --created ">=$SINCE" --json databaseId --jq '.[0].databaseId') ``` Compute `SINCE` as "5 minutes ago" in UTC ISO-8601. `date` flags differ between macOS (`date -u -v-5M`) and GNU/Linux (`date -u -d '5 minutes ago'`) — detect which is available (`date -v-5M +%s >/dev/null 2>&1` succeeds on BSD/macOS date) and use the matching form, since this skill runs on a user's local machine, not just CI. If `RUN_ID` comes back empty, wait a bit longer and retry — don't fail immediately. ## Step 6 — Monitor the workflow run Poll every ~15 seconds. **Avoid the bash variable name `status`** in polling scripts — it's a read-only/special variable in some shells and assigning to it crashes the script with `read-only variable: status`; use `run_status`/`run_conclusion` instead. ```bash gh run view "$RUN_ID" --repo <owner>/<repo> --json status,conclusion ``` until `status == "completed"`. If `conclusion != "success"` (or `status` is `cancelled` or `failure`), don't stop immediately — first check whether the failure is a **real** problem or a **transient infra blip**, since the two need very different responses: 1. Run `gh run view "$RUN_ID" --repo <owner>/<repo> --log-failed` and read the actual error. 2. **Transient/infra signatures** — retry automatically without asking, since these are noise, not signal: - The `Check Releasability` job re-checking the exact commit SHA (this happens even though Step 2 already passed the pre-flight check — the workflow's own check is authoritative and re-runs independently, per Step 2's caveat) fails one specific sub-check with a network-level error rather than a real business-rule violation, e.g. `java.lang.IllegalStateException: java.io.IOException: Connection reset` on the `Jira` sub-check while every other sub-check (`QA`, `GitHub`, `ParentPOM`, `CheckDependencies`, `QualityGate`, etc.) passed. This is a dropped connection to the lambda backing that one check, not an actual unresolved-ticket problem — Step 2 already ruled that out. - Any other single-job failure whose log shows a connection/timeout/network error unrelated to the actual release logic. - In these cases: tell the user plainly what failed and why it looks transient (name the