sfdx-hardis 8.7.1 → 8.8.0

package/lib/commands/hardis/project/deploy/smart.js

@@ -200,7 +200,7 @@ Deployment actions and selected Apex test classes are scoped to the Pull Request
 
 If the deployment job of a feature branch fails, its actions are not picked up by the next merged Pull Request: re-run the failed deployment job, or move the actions to a new Pull Request.
 
-With \`enablePromotionBranches: true\`, a merge from a [promotion branch (experimental)](${CONSTANTS.DOC_URL_ROOT}/salesforce-ci-cd-promotion-branches/) (named \`promotion/<source>/<target>/<YYYY-MM-DD>-<counter>\`, ex: \`promotion/uat/preprod/2026-09-06-1\`, assembled by cherry-picking approved User Stories) keeps the deployment actions, Apex test classes and custom behaviors (NO_DELTA, PURGE_FLOW_VERSIONS...) of the Pull Requests declared in its description with \`promotionPullRequests: [482, 487]\`.
+With \`enablePromotionBranches: true\`, a merge from a [promotion branch (experimental)](${CONSTANTS.DOC_URL_ROOT}/salesforce-ci-cd-promotion-branches/) (named \`promotion/<source>/<target>/<YYYY-MM-DD>-<HHMM>\`, ex: \`promotion/uat/preprod/2026-09-06-1430\`, assembled by cherry-picking approved User Stories) keeps the deployment actions, Apex test classes and custom behaviors (NO_DELTA, PURGE_FLOW_VERSIONS...) of the Pull Requests declared in its description with \`promotionPullRequests: [482, 487]\`.
 
 After every action runs, its result (✅ success, ❌ failed, 👋 manual) is recorded in a dedicated **"Deployment Actions"** PR comment - ordered by org (integration → uat → preprod → prod) - regardless of \`runOnlyOnceByOrg\`.
 

package/lib/commands/hardis/project/promotion/create.js

@@ -25,7 +25,7 @@ This is the only supported way to create a [promotion branch (experimental)](${C
 - checks that \`enablePromotionBranches: true\` is set in the sfdx-hardis configuration;
 - checks that \`allowedPromotionSteps\` declares the steps promotions may run on (ex: \`- source: uat\` / \`target: preprod\`), and keeps to them: only those source and target branches are offered, and naming another one fails;
 - lists the Pull Requests merged into the source branch and not yet promoted to the target branch, and lets you select the ones to carry (or takes them from \`--pull-requests\`). A Pull Request another promotion branch already carries to the same target is left out, unless \`--include-already-promoted\` is passed;
-- creates the branch from the target branch, named \`promotion/<source>/<target>/<YYYY-MM-DD>-<counter>\` (ex: \`promotion/uat/preprod/2026-09-06-1\`), the counter separating several promotions assembled the same day;
+- creates the branch from the target branch, named \`promotion/<source>/<target>/<YYYY-MM-DD>-<HHMM>\` (UTC, ex: \`promotion/uat/preprod/2026-09-06-1430\`), with \`-2\`, \`-3\`... added only when that name is already taken;
 - cherry-picks the merge commit of each selected Pull Request, oldest first, with \`-x\` so each commit keeps a pointer to its origin;
 - pushes the branch and creates the Pull Request to the target branch, with a description declaring the carried Pull Requests (\`${PROMOTION_PULL_REQUESTS_KEY}\`), their titles, authors, source branches and tickets.
 
@@ -45,7 +45,7 @@ On a cherry-pick conflict, you choose (or \`--on-conflict\` decides) to:
 - A first-parent commit that only moves other merges (a major-to-major sync like \`integration -> uat\`, a promotion branch merged into its target) is opened up into the first-parent commits it brought in, so each User Story is a candidate of its own instead of the whole sync window being a single row.
 - The branch is created with \`git checkout -b <name> origin/<target>\`, commits are applied with \`git cherry-pick -x\` (\`-m 1\` for merge commits).
 - The Pull Request is created through the git provider API (GitHub, GitLab, Azure DevOps, Bitbucket token), or with the \`gh\` CLI on GitHub. The creation is retried a few times: the branch is pushed a fraction of a second before, and a provider that has not indexed the new ref yet answers that the source branch does not exist. Without either, the branch is pushed and the description is saved under \`hardis-report/\` to create the Pull Request by hand, and the message names the reason the provider gave.
-- The counter is computed from the existing \`promotion/<source>/<target>/<date>-*\` branches, local and remote.
+- The date and the time are in UTC. The name is checked against every promotion branch of the step that exists or existed: local and remote branches, remote-tracking refs, the merge commits of the target branch and its Pull Requests merged in the last two days. A name already taken gets \`-2\`, \`-3\`..., one more than the highest one found, and the branch creation stops on a name that still exists instead of resuming that branch.
 </details>
 
 ### Agent Mode

package/lib/commands/hardis/work/backpromote.d.ts

@@ -7,5 +7,52 @@ export default class BackpromoteTask extends SfCommand<any> {
     static flags: any;
     static requiresProject: boolean;
     protected static requiresSfdxPlugins: string[];
+    private flags;
     run(): Promise<AnyJson>;
+    private listPullRequestsAndHistory;
+    /**
+     * The files of one Pull Request of a listed merge. A merge that brought a single Pull Request gives
+     * it all its files. A merge that brought several (a retrofit of main into integration) gives each
+     * one the files of its own merge commit, kept only when the merge on the parent branch changed them
+     * too: a file main changed that the parent branch already had is not backpromoted.
+     */
+    private filesOfPullRequest;
+    /** The files a listed merge changed, from the single git call of the listing, or from git for a merge outside it */
+    private filesOfGroup;
+    /** The number of the start Pull Request (0 for a merge without number), or null when there is no window */
+    private chooseStart;
+    private computeWindow;
+    /** The deployment actions of the given groups, with what already ran in this sandbox */
+    private collectActions;
+    private readNoOverwrite;
+    private compare;
+    /**
+     * The package-no-overwrite.xml items this run does not deploy: the ones already in the sandbox,
+     * unless --include-no-overwrite names them (R22). One absent from the sandbox is deployed like any
+     * other item. Needs the comparison.
+     */
+    private heldNoOverwriteKeys;
+    /** Terminal mode: the items, the deletions and the decision for every file that differs */
+    private askDecisions;
+    private applyDecisions;
+    private persistState;
+    private switchCheckout;
+    /** Write the files marked merge that are not prepared yet, and the coding agent prompt */
+    private prepareMerges;
+    private waitForMerges;
+    private deployAndRecord;
+    private writeConfirmedActions;
+    private confirmActions;
+    private resetBranch;
+    private runCommand;
+    /**
+     * A failed deployment: the components the sandbox refused travel in the result, and the message
+     * says what to do with them (fix them on the backpromote branch, or untick them), so that the panel
+     * shows the errors themselves instead of pointing at a log it does not display.
+     */
+    private deployFailure;
+    private buildPlan;
+    private emptyPlan;
+    /** A refusal: exit code 1, the plan in the JSON data so that the panel and an agent read the status */
+    private refusal;
 }