Does v12 fix merge_deploy_mode skipping deployment after a failed branch deployment? #509

Details

We observed merge_deploy_mode returning continue=false after a failed branch deployment, because its commit tree matched the subsequently merged default-branch commit.

Our integration uses a multi-job start/build/deploy/complete pattern. The start wrapper pins github/branch-deploy v11.1.4 (ddf8ca48e9cdb2d2c7c71dee428308b19af9313f). When the build failed, the completion job correctly recorded a failure deployment status.

Observed sequence

1. Trigger a branch deployment for a PR.
2. The action creates a deployment with payload type branch-deploy.
3. The build fails before the application is deployed.
4. The completion job sets the deployment status to failure.
5. Merge the PR; the merged commit has the same Git tree as the PR head.
6. Run the merge-deployment check on the default-branch push:

- uses: github/branch-deploy@ddf8ca48e9cdb2d2c7c71dee428308b19af9313f # v11.1.4
  id: check
  with:
    merge_deploy_mode: true
    environment: development

The action reports that the trees are equal and that deployments are up to date, returning continue=false. Consequently, no deployment runs, although the branch deployment failed.

We verified through the GitHub API that the relevant deployment has GraphQL state FAILURE and latest deployment status FAILURE.

Version comparison and questions

The v11.1.4/v11.1.5 implementation appears to compare deployment trees without checking deployment state. In contrast, v12.0.0/v12.0.1 only obtains the deployment tree when latestDeployment.state === 'ACTIVE', and the current merge-strategy documentation explicitly states that failed deployments require a new deployment.

Is this failure case intentionally fixed by the v12 changes, making migration to v12 the supported solution? Is there an existing issue/PR documenting the fix, or a v11 backport available or planned?

Our expectation is that redundant deployment suppression should apply only when the matching tree was successfully deployed, not merely when a deployment was attempted.

We have reproduced the behavior on v11.1.4; we have not yet tested our wrapper with v12.