Promotion Branches E2E Test

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:

   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 <label> <expectations.json>. The job logs and the Pull Request comments say nothing about the view the release manager actually reads. 5bis-bis. Run the deployment actions section (runbook section 6quater): deployment-actions-run.sh, after promotion-run.sh. It turns failValidationOnPendingManualActions on (off by default), checks that a pre-deployment manual action stops the validation (not on a draft), the retry of a failed action, set-status here and ahead in the next branch, the forecast of the next promotion, and, with DEV_ORG, the runs in a developer org. 5bis-ter. Run the same features through real CI (runbook section 6quinquies): ci-workflows-run.sh, with its own REPO, WORK and LOGS. The simulators prove the CLI; this proves the workflows a project really runs, with the branch linked by sf plugins link. 5bis-quater. Run the identical actions section (runbook section 6sexies): identical-actions-run.sh, after promotion-run.sh. Eight stories promoted together to uat: the action they share runs once (the counter file says how many times it really ran), an action written twice in one story runs twice, a reused id runs for each story, and a copy met after a failure is recorded as done. Then the backpromote of that window, the same action in the branch config and in a story, and the validation job running an action with context all. 5quater. Run backpromote (Beta) (runbook section 6bis): backpromote-setup.sh then backpromote-steps.sh, against scratch orgs created from the Dev Hub. Steps B0 to B16: no git provider token, refused orgs (major branch org, production), refused parent branch, the first plan with no history and its progress file, the run from S1 with the deployment actions and the "Backpromotes" comments, up to date and a manual action confirmed, the default start after a new story, a file that differs overwritten, the org version kept then offered again, the agent protocol (waitingForMerges, solve, run again, branch pushed), the panel protocol (--prepare, refused while markers remain, run), a deletion skipped then applied, an excluded item that comes back, a dirty working tree stashed, a refreshed sandbox (same name, other org id), the scan limit and the reset. Assert each JSON document with backpromote_check and the comments with backpromote_comments_check (C1 to C4).

6. Check the diagram rule: node scripts/check-diagram.cjs <owner>/<repo> integration,uat,preprod,main (check-diagram-gitlab.cjs / check-diagram-azure.cjs for the other two providers).

7. Run the flag-off A/B regression check (runbook section 7ter). TOTAL DIFFERING LINES: 0, or 1 when a merged branch is named promotion/....

8. Write the report in this skill's reports/ folder, one per provider: .claude/skills/promotion-branches-e2e/reports/promotion-branches-e2e-report-github.md, …-gitlab.md, …-azure.md and …-bitbucket.md. Never write them at the repository root. Pipeline under test, the stories, the promotions performed, a table per test group with expected versus result (backpromote steps B0 to B9 included), what the run found, what it did not cover, and the suite counts. Overwrite the previous reports.

Rules for the run

• Fix what you find, inside the run. Every previous run found real defects. When a job log disagrees with the runbook, decide which one is wrong: fix the product, or fix the runbook and say so in the report.
• Be autonomous. Do not stop to ask whether to continue.
• Report honestly. A check that could not be run is "not covered", never "OK". The report's "What this run did not cover" section is not optional.
• Update the runbook whenever you hit a trap that cost you time, so the next run does not.

Known gaps of every run so far

State them again in the report unless you close them:

• The four providers were all run live on 2026-09-07 and 2026-09-08; GitHub and GitLab again on 2026-09-13, with sections 3, 4 and 6 scripted. Bitbucket has not been run since 2026-09-08: its only access token is scoped to a repository that no longer exists (404 on it, 403 on repository creation), so a new token is needed before the next Bitbucket run.
• The four pipeline levels share one Salesforce org, so deployment action state is keyed by org branch, not by distinct orgs.
• The pipeline webview is exercised through its own data provider (section 4bis), its compiled helpers and its unit tests, not by clicking: the mermaid is asserted as text, never rendered.
• Backpromote (Beta) ran on GitHub and GitLab (2026-09-13). Its Bitbucket and Azure DevOps hooks exist in the libraries but have never run. Its VS Code panel is not clicked: the panel reads the same --json documents the run asserts, and its command builder, greying rules and marker watch are unit tested. The terminal prompts of step B17 are only covered when someone answers them by hand. The retry of a comment read after a dropped connection only runs when the provider drops one.
• Section 6sexies (identical actions, sfdx-hardis#2271) ran on GitHub and GitLab on 2026-10-04, twice on GitHub (IA_RUN=2), and W9 ran it through real GitHub Actions. Identical copies of custom function actions with outputs, and of actions with a customUsername, are unit tested only.
• scripts/promotion-provider.sh covers GitHub and GitLab only: Azure DevOps and Bitbucket still run sections 4 and 6 by hand with their own libraries.

$ARGUMENTS