--- name: promotion-branches-e2e description: Run the hardcore end to end test of the promotion branches feature, and of backpromote (Beta), against real Salesforce orgs and a throwaway private GitHub, GitLab or Azure DevOps repository, then write the report. Use when promotion branches (enablePromotionBranches, hardis:project:promotion:create) or backpromote (hardis:work:backpromote, the VS Code Backpromote panel) changed and must be proven again, or when the user asks for the promotion branches / backpromote end to end / hardcore test. argument-hint: "[org username] [repo slug] [what to focus on]" allowed-tools: Bash, Read, Grep, Glob, Edit, Write, AskUserQuestion user-invocable: true model: opus --- # Promotion branches: end to end test Rebuild, from nothing, a four level pipeline that exercises every path of the promotion branches feature against a real Salesforce org, assert every job log, then write the report. Roughly 45 minutes of wall clock. The design of the feature itself is in the `promotion-branches` skill: read it first if you have not already, so you know what each assertion is protecting. ## What this skill contains | File | Use | |-------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `reference/runbook.md` | The full procedure: repository layout, the six User Stories, the run order, what to assert in each log, the edge cases, the traps. **Read it before starting.** | | `scripts/build-repo.sh` | Writes the base project, the four major branches and the config. Provider agnostic. | | `scripts/stories.sh` | `story_branch` and `story_actions`: the six User Stories and the action files that travel with them. Provider agnostic. | | `scripts/e2e-lib.sh` | GitHub job simulators: `e2e_check`, `e2e_deploy`, `e2e_promote`, `e2e_release_notes`, `e2e_grep`. Source it. | | `scripts/e2e-lib-gitlab.sh` | The same for GitLab, plus `gl_mr_create`, `gl_mr_merge` and the merge-ref wait GitLab needs. | | `scripts/check-pipeline.cjs` | Drives the extension's own PipelineDataProvider against the test repository and asserts what the DevOps Pipeline shows at a point of the run. | | `scripts/check-diagram.cjs` | Feeds the extension's compiled helpers with the real Pull Requests and asserts the "single place in the diagram" rule. | | `scripts/check-diagram-gitlab.cjs` | The same, reading merge requests from the GitLab API. | | `scripts/check-backpromote-plan.cjs` | Asserts a `hardis:work:backpromote ... --json` document (plan version 3: plan, prepare, run, confirm, reset) against the expectations of `reference/backpromote/*.json` (section 6bis). | | `scripts/check-backpromote-comments.cjs` | Asserts the "Backpromotes" Pull Request comments of a `dump_pr_comments` dump: one comment per Pull Request, its sandbox rows and action rows (section 6bis, C1 to C4). | | `scripts/check-backpromote-identical.cjs` | Asserts the identical actions of a backpromote `--plan --json` document or run result: `identicalTo`, one key per action, the outcome of each key (section 6sexies). | | `scripts/promotion-provider.sh` | Provider neutral job names (`p_check`, `p_deploy`, `p_promote`, `p_open`, `p_merge`...) over the GitHub or GitLab library, picked with `PROVIDER`. | | `scripts/promotion-run.sh` | Sections 3, 4 and 4bis scripted: the six stories, the four promotions, the release notes, the retrofit, an assertion per job log and a pipeline check per step. | | `scripts/promotion-edge.sh` | Section 6 scripted in five groups (`g1` to `g5`) that build on each other, run after `promotion-run.sh`. | | `scripts/deployment-actions-run.sh` | Section 6quater scripted: the manual action gate of validations, a failed action retried with `action:run`, `set-status` (also ahead in the next branch), the promotion forecast and the developer org runs. After `promotion-run.sh`. | | `scripts/identical-actions-run.sh` | Section 6sexies: an action shared by several stories runs once in the promotion to uat; a repeat inside one story, another phase, a reused id, a copy after a failure, the forecast, the re-run, the branch config, the validation job, the backpromote. After `promotion-run.sh`. | | `scripts/section-lib.sh` | The assertion helpers of the section scripts (`record`, `assert_log`, `job`, `cli`, `status_check`, `open_story`). Sourced by `deployment-actions-run.sh` and `identical-actions-run.sh`. | | `scripts/check-action-status.cjs` | Asserts an `action:list --with-status [--forecast] [--with-backpromotes] --json` document: statuses, notes, forecasts and the identical action of a copy, the promotion carried, Backpromotes rows. | | `scripts/ci-workflows-prepare.cjs` | The GitHub Actions workflows of the CI section: the sfdx-hardis templates plus a step that links the branch under test and `SFDX_AUTH_URL_` logins. | | `scripts/ci-workflows-run.sh` | Section 6quinquies: the gate, the checkbox, a real draft, the deployment, the promotion and its forecast, the same action in two stories, run by REAL GitHub Actions jobs in a repository of its own. | | `scripts/timing-report.cjs` | Performance tables of a run: `timings.tsv` (every job and backpromote call) and the backpromote progress files, median and worst per step, slowest calls. | | `scripts/ab-run.sh` | Runs the same CI jobs with a given CLI checkout and stores the logs. | | `scripts/ab-run-gitlab.sh` | The same on GitLab. | | `scripts/ab-run-azure.sh` | The same on Azure DevOps. | | `scripts/ab-run-bitbucket.sh` | The same on Bitbucket Cloud. | | `scripts/audit-pr-comments.cjs` | The Pull Request comment audit, shared by the four providers. Fed by the `dump_pr_comments` of each library. | | `scripts/ab-diff.py` | Normalises two log folders and diffs them: the flag-off regression proof. | ## Before starting Ask the user only for what you cannot find yourself: - the **Salesforce org** to deploy to (an authenticated org alias or username); - for backpromote (Beta), a **Dev Hub** to create the developer's scratch orgs from (the org above when it has Dev Hub enabled): backpromote refuses production orgs and major branch orgs, and a scratch org tracks its sources, which is what the "pending org changes are saved first" step needs; - the **repository slug** to create, if they care about the name. Otherwise pick `/sfdx-hardis-promo-e2e-`, incrementing `` past the ones that already exist; on GitLab, `/sfdx-hardis-promo-e2e-gl-`; on Azure DevOps, `sfdx-hardis-promo-e2e-az-` inside an existing team project; - which **providers** to run, when they have not said. GitHub alone is the quick pass; each of GitLab and Azure DevOps is the only way its own provider code gets exercised. Check yourself: `gh auth status`, `glab auth status`, the Azure DevOps PAT in `.env` (`AZURE_PERSONAL_ACCESS_TOKEN`), `sf org list`, the sfdx-hardis branch under test, and whether the vscode-sfdx-hardis working copy is on the matching branch and compiled (`yarn compile`), which the diagram check needs. **Never reuse a previous test repository.** Each run starts from a fresh private repository, so a failure cannot be an artefact of the previous run's state. ## Process 1. **Read `reference/runbook.md` in full.** It holds the decisions that make the run meaningful (development branch named `integration` so stories arrive through a child branch, `hardis-report/` deliberately not gitignored, one static resource per story, never squash). 2. **Set the environment and source the library**: ```bash export ORG="..." REPO="..." WORK="/c/tmp/promo-e2e" LOGS="/c/tmp/promo-e2e-logs" export DEV="C:/git/sfdx-hardis/bin/dev.js" source .claude/skills/promotion-branches-e2e/scripts/e2e-lib.sh ``` 3. **Build the repository and the stories** (runbook sections 2 and 3). 4. **Run the pipeline** (runbook section 4), asserting each log as you go with `e2e_grep`. Do not batch the assertions to the end: a wrong scope early makes every later log meaningless. 5. **Run the edge cases** (runbook section 6). These are where the defects have been. 5bis. **Audit the Pull Request comments** (runbook section 5bis). The job logs say what the command decided; the audit says what the reviewer reads. Four of the defects of 2026-09-08 came from it, and none of them was visible in a job log. 5ter. **Check the DevOps Pipeline before and after every promotion operation** (runbook section 4bis): `pipeline_check