fix(deploy): collect the right Pull Request scope for deployment actions and Apex test classes on every merge (#2054)

* fix(deploy): scope deployment actions and Apex test classes to the merged Pull Request

Merging a feature branch into a major branch reported and executed the
deployment actions of every other Pull Request of the batch, because
listAllPullRequestsForCurrentScope discards the merged Pull Request in
deployment mode and re-derives the scope from the branch strategy. One feature
merge could therefore run an action belonging to another Pull Request, and
attribute it to the wrong one in the Slack notification and in the Pull Request
comment.

The scope is now the merged Pull Request alone when its source branch is
neither a major branch nor a retrofit branch. A merge between major branches,
or from a retrofit branch, keeps collecting the batch, because those carry the
Pull Requests merged into the source major branch since its last promotion.

The scoping happens at collection time, so deployment actions, the Apex test
classes selected from Pull Requests, the deployment notification, the Pull
Request comment and the per-PR "Deployment Actions" state comment all follow it
without any of them needing a filter of their own.

Side effect worth noting: the single Pull Request scope no longer depends on
mergeTargets being configured. A feature merge into a major branch whose config
declares no merge target used to collect nothing at all, silently dropping the
merged Pull Request's own actions.

* [MegaLinter] Apply linters fixes

* fix(deploy): run deployment actions on go-live merges, retrofitted upstream PRs and GitHub push deploys (#2055)

* fix(deploy): run deployment actions on go-live merges, retrofitted upstream PRs and GitHub push deploys

Three holes in the Pull Request scope collection prevented deployment actions
and selected Apex test classes from running in major orgs where they had not
been performed yet.

Production merges collected nothing. The batch window is anchored on the
target branch's mergeTargets, and a production branch has none, so a
preprod -> main merge returned an empty scope: no action ran and no test class
was selected on the go-live deployment. The scope is now the batch of Pull
Requests carried by the go-live merge itself, through the existing
listPullRequestsInGoLive provider method, bounded by the merge commit's first
parent. When the merge commit is unknown, the scope falls back to the merged
Pull Request alone instead of nothing.

Upstream Pull Requests were invisible to retrofits. The window collectors only
fetched Pull Requests whose base is the window branch or one of its children,
so a hotfix merged into main was never collected when a retrofit branch
brought its commits down to integration. Every major branch is now part of the
search list: matching stays bounded by the window's commit SHAs, so an
upstream Pull Request is only collected when its merge commit actually arrived
in the window.

GitHub push-triggered deployments never entered the engine at all. Without a
Pull Request number, the GraphQL commit lookup selected neither the head and
base ref names nor the merge commit, so the resolved Pull Request had empty
source and target branches and the scope resolution bailed out immediately.
The query now selects them and maps the node to the shape the common Pull
Request info builder reads, which also fixes the empty author and web URL.

* docs(deploy): correct the search-branches example comment in listAllPullRequestsForCurrentScope

---------

Co-authored-by: nvuillam <17500430+nvuillam@users.noreply.github.com>

Author: nvuillam

CHANGELOG.md

@@ -31,6 +31,10 @@
 - A destructive changes manifest configured through `packageXmlToDelete` / `packageXmlToDeletePreDeploy` that does not exist on disk now logs a warning, instead of being skipped silently.
 - **Behavior change: post-deployment actions are no longer run when the metadata deployment failed.** They are reported as `not run` in the Pull Request comment, no execution state is stored, and the job now fails on the deployment error instead of on a post-deployment action error. The `skipIfError` property is removed, and is ignored if still present in your configuration.<br/>**Check your configuration before upgrading: an action relying on `skipIfError: false` to run after a failed deployment will no longer run.**
 - Deployment actions: a failed action now displays why it failed in the job log and in the Pull Request comment. Actions whose command ends with `--json` used to fail with no output at all.
+- Deployment actions and selected Apex test classes: merging a feature branch now processes only the Pull Request just merged, while merges between major branches and from `retrofit/*` branches keep replaying the whole batch of upstream Pull Requests.
+- Deployment actions and selected Apex test classes now also run on merges into the production branch, scoped to the Pull Requests carried by the go-live merge.
+- Deployment actions of Pull Requests merged upstream (like a hotfix in `main`) are now replayed downstream when a retrofit branch brings their commits to another major branch.
+- Fix deployment actions never running on GitHub push-triggered deployment jobs, caused by incomplete Pull Request detection.
 
 ### CI/CD
 

docs/hardis/project/deploy/smart.md

@@ -161,6 +161,10 @@ You can define command lines to run before or after a deployment, with parameter
 
 Post-deployment actions are never run when the metadata deployment failed: they are reported as `not run` and are proposed again during the next successful deployment.
 
+Deployment actions and selected Apex test classes are scoped to the Pull Request that has just been merged when it comes from a feature branch. A merge from a major branch (ex: integration -> uat) or from a retrofit branch (ex: retrofit/from-main -> integration) keeps those of every Pull Request merged into the source major branch since its last promotion, and a merge into the production branch keeps those of every Pull Request carried by the go-live merge. Pull Requests merged upstream (ex: a hotfix in main) are included as soon as their commits arrive in the window.
+
+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.
+
 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`.
 
 If the commands are not the same depending on the target org, you can define them into **config/branches/.sfdx-hardis-BRANCHNAME.yml** instead of root **config/.sfdx-hardis.yml**

docs/hardis/project/deploy/sources/dx.md

@@ -161,6 +161,10 @@ You can define command lines to run before or after a deployment, with parameter
 
 Post-deployment actions are never run when the metadata deployment failed: they are reported as `not run` and are proposed again during the next successful deployment.
 
+Deployment actions and selected Apex test classes are scoped to the Pull Request that has just been merged when it comes from a feature branch. A merge from a major branch (ex: integration -> uat) or from a retrofit branch (ex: retrofit/from-main -> integration) keeps those of every Pull Request merged into the source major branch since its last promotion, and a merge into the production branch keeps those of every Pull Request carried by the go-live merge. Pull Requests merged upstream (ex: a hotfix in main) are included as soon as their commits arrive in the window.
+
+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.
+
 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`.
 
 If the commands are not the same depending on the target org, you can define them into **config/branches/.sfdx-hardis-BRANCHNAME.yml** instead of root **config/.sfdx-hardis.yml**

docs/salesforce-ci-cd-smart-deployment.md

@@ -373,7 +373,11 @@ Pull Request descriptions can also override config properties using YAML blocks
 ```mermaid
 %%{init: {"theme": "base", "themeVariables": {"primaryColor": "#eaf5fe", "primaryTextColor": "#032d60", "primaryBorderColor": "#0176d3", "lineColor": "#0176d3", "fontFamily": "Salesforce Sans, Arial, sans-serif"}}}%%
 flowchart TD
-    CMD_START[executePrePostCommands] --> SOURCES[Collect commands from:<br/>1. Branch config<br/>2. Extra commands from PR<br/>3. PR description YAML blocks]
+    CMD_START[executePrePostCommands] --> SCOPE{Merge from a<br/>feature branch?}
+    SCOPE -->|Yes| ONE_PR[Scope: the merged PR only]
+    SCOPE -->|No: major or retrofit branch| BATCH[Scope: all PRs since<br/>the previous merge]
+    ONE_PR --> SOURCES[Collect commands from:<br/>1. Branch config<br/>2. Extra commands from PR<br/>3. PR description YAML blocks]
+    BATCH --> SOURCES
     SOURCES --> DEPLOY_KO{Metadata deployment<br/>failed?}
     DEPLOY_KO -->|Yes| SKIP_ERR[Report every action as<br/>not run and stop]
     DEPLOY_KO -->|No| LOOP{For each command}
@@ -395,8 +399,8 @@ flowchart TD
     classDef sfSuccess fill:#cdefc4,stroke:#2e844a,color:#194e31,stroke-width:1.5px
     classDef sfSkip fill:#f3f3f3,stroke:#706e6b,color:#3e3e3c,stroke-width:1px
 
-    class CMD_START,SOURCES sfAction
-    class LOOP,VALID,DEPLOY_KO,CTX_CHECK,ONCE_CHECK sfDecision
+    class CMD_START,SOURCES,ONE_PR,BATCH sfAction
+    class LOOP,VALID,SCOPE,DEPLOY_KO,CTX_CHECK,ONCE_CHECK sfDecision
     class EXEC sfSuccess
     class SKIP_INVALID,SKIP_ERR,SKIP_CTX,SKIP_ONCE sfSkip
 ```
@@ -416,6 +420,8 @@ All action types support the following common properties: `id`, `label`, `contex
 
 Post-deployment actions are never run when the metadata deployment failed. They are reported as `not run` in the Pull Request comment, no execution state is stored, and they are proposed again during the next successful deployment.
 
+A merge from a feature branch only processes the actions and the Apex test classes of the Pull Request that has just been merged. A merge between major branches, or from a retrofit branch (`retrofit/*`), processes those of every Pull Request merged into the source major branch since its last promotion. A merge into the production branch processes those of every Pull Request carried by the go-live merge. Pull Requests merged upstream (ex: a hotfix in `main`) are included as soon as their commits arrive in the window, for example through a retrofit branch.
+
 Command context options:
 
 - `all` (default), runs in both check and process modes

docs/salesforce-ci-cd-work-on-task-deployment-actions.md

@@ -89,6 +89,28 @@ Each action is an object with the following required and optional properties.
 
 > Post-deployment actions are never run when the metadata deployment failed. They are reported as `not run` in the Pull Request comment, no execution state is stored for them, and they are proposed again during the next successful deployment.
 
+### Which Pull Requests are in scope
+
+The actions collected for a deployment depend on the branch the merged Pull Request comes from.
+
+| Merge                                                              | Scope                                              |
+|--------------------------------------------------------------------|----------------------------------------------------|
+| From a feature branch (ex: `feature/my-story` -> `integration`)    | Only the Pull Request that has just been merged    |
+| Between major branches (ex: `integration` -> `uat`)                | Every Pull Request merged since the previous merge |
+| From a retrofit branch (ex: `retrofit/from-main` -> `integration`) | Every Pull Request merged since the previous merge |
+
+A feature branch merge carries a single Pull Request, so its notification and its Pull Request comment list only that Pull Request's actions. A major branch or retrofit branch merge carries a batch of Pull Requests, whose actions must be replayed in the target org.
+
+- Between major branches, the batch is every Pull Request merged into the source major branch since its last promotion.
+- Into the production branch (which has no promotion target), the batch is every Pull Request carried by the go-live merge itself.
+- Pull Requests merged into upstream branches are part of the batch as soon as their commits arrive in the window: a hotfix merged into `main` is collected when a retrofit branch brings it down to `integration`, so its actions run there too.
+
+In every case, `runOnlyOnceByOrg` state tracking ensures each action runs only in the orgs where it has not been performed yet.
+
+The same scope applies to the Apex test classes selected from Pull Requests when `enableDeploymentApexTestClasses` is active.
+
+> 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 open a new Pull Request carrying the actions of the previous one.
+
 ### Deployment Actions PR comment
 
 After every action runs, sfdx-hardis creates or updates a dedicated **"Deployment Actions"** comment on the Pull Request. This gives release managers a consolidated view of what has been executed across every org for the lifetime of the PR.

src/commands/hardis/project/deploy/smart.ts

@@ -206,6 +206,10 @@ You can define command lines to run before or after a deployment, with parameter
 
 Post-deployment actions are never run when the metadata deployment failed: they are reported as \`not run\` and are proposed again during the next successful deployment.
 
+Deployment actions and selected Apex test classes are scoped to the Pull Request that has just been merged when it comes from a feature branch. A merge from a major branch (ex: integration -> uat) or from a retrofit branch (ex: retrofit/from-main -> integration) keeps those of every Pull Request merged into the source major branch since its last promotion, and a merge into the production branch keeps those of every Pull Request carried by the go-live merge. Pull Requests merged upstream (ex: a hotfix in main) are included as soon as their commits arrive in the window.
+
+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.
+
 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\`.
 
 If the commands are not the same depending on the target org, you can define them into **config/branches/.sfdx-hardis-BRANCHNAME.yml** instead of root **config/.sfdx-hardis.yml**

src/common/gitProvider/github.ts

@@ -303,6 +303,13 @@ export class GithubProvider extends GitProviderRoot {
                     body
                     url
                     merged,
+                    headRefName
+                    baseRefName
+                    mergeCommit {
+                      oid
+                    }
+                    createdAt
+                    mergedAt
                     baseRef {
                       id
                       name
@@ -333,7 +340,21 @@ export class GithubProvider extends GitProviderRoot {
         (pr: any) => pr.node.merged === true && pr.node.baseRef.name === currentGitBranch,
       );
       if (candidatePullRequests.length > 0) {
-        return this.completePullRequestInfo(candidatePullRequests[0].node);
+        // The GraphQL node does not have the REST shape completePullRequestInfo reads
+        // (head.ref / base.ref / merge_commit_sha / user.login / html_url), so map it first.
+        // Without this, push-triggered deployments got a Pull Request with empty source and
+        // target branches, and the deployment actions engine could not resolve its scope.
+        const node = candidatePullRequests[0].node;
+        return this.completePullRequestInfo({
+          ...node,
+          head: { ref: node.headRefName || "" },
+          base: { ref: node.baseRefName || node.baseRef?.name || "" },
+          merge_commit_sha: node.mergeCommit?.oid || undefined,
+          created_at: node.createdAt || undefined,
+          merged_at: node.mergedAt || undefined,
+          user: { login: node.author?.login || "" },
+          html_url: node.url || "",
+        });
       }
     }
     uxLog("log", this, c.grey('[GitHub Integration] ' + t('githubUnableToFindPrInfo')));

src/common/utils/orgConfigUtils.ts

@@ -272,6 +272,19 @@ export function isUatRun(branchName) {
   return (branchName.toLowerCase().startsWith("uat") || branchName.toLowerCase().startsWith("recette")) && branchName.toLowerCase().includes("run");
 }
 
+/**
+ * A retrofit branch carries the changes of an upstream major branch down to another one
+ * (ex: main is merged into retrofit/from-main, which is then merged into integration).
+ * Retrofit branches have no org config file, so they never appear in listMajorOrgs():
+ * they are identified by their name, like the other branch kinds above.
+ */
+export function isRetrofit(branchName: string): boolean {
+  // Matches the retrofit/<name> convention produced by hardis:work:new, so an ordinary branch
+  // named retrofit-JIRA-123 or retrofitting-legacy is not mistaken for one.
+  const name = (branchName || "").toLowerCase();
+  return name === "retrofit" || name.startsWith("retrofit/");
+}
+
 /**
  * Get the Chrome/Chromium executable path for Puppeteer
  * This is used by various commands that need browser automation