An old commit appears in a deployment and there was no force pushes or rebasing

Summary

When a user reviews a deployment to run, an old commit already deployed to an environment shows up in the list of commits for the new deployment and can cause issues for external processes that rely on the list of commits.

Cause

Ideal Scenario:

Any deployment to an environment includes only the commits that were not deployed before. This means, the list of commits reachable from the current/latest commit for deployment and commits not reachable from the previously deployed commit.

Example:

1. Let's say the latest commit deployed to the staging environment is commit S(702824a) which is on the main branch

2. Create a feature branch from the main branch and add a few commits - A(fde78ca) and B(54bb14e)

3. Deploy these commits from the feature branch to the staging environment, deployment D1(#4386)

   

4. Create a pull request from feature to the main branch

5. Merge the pull request with a merge commit strategy, 96ab4d2 is the merge commit in this example.

6. Deploy the merge commit to the staging environment - deployment D2(#4387), we could see that only the new merge commit is included in the commits list.

   
   We use the API - https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-commits-post to populate the list of commits in a deployment. 

Issue:

There are certain scenarios where the commits deployed in D1(older) are still included in deployment D2(new). We'll cover one such scenario in this KB article.

Steps to reproduce:

The steps to reproduce are the same as before described in our ideal scenario except for deleting the feature branch on merge with "Close source branch" on merge option with squash merge strategy. Continuing with the same example as above,

1. Let's say the latest commit deployed to staging environment is commit S(96ab4d2) which is on the main branch

2. Create a feature branch from the main branch and add a few commits - A(d917717) and B(3896937)

3. Deploy these commits from feature branch to the staging environment, deployment D1(#4388)

   

4. Create a pull request from feature to the main branch

5. Merge the pull request with a squash merge strategy, 224328c is the merge commit in this example.

6. Deploy the commit from merge to the staging environment - deployment D2(#4388), we could see that all the previously deployed commits are in the list.

   

ℹ️ If the source branch is not deleted, it means the commit S is still in the repository and is reachable. So we wouldn't be seeing all the past commits in the deployments.

Solution

The behavior occurs from performing a squash merge and deleting the source branch. If the source branch is not deleted, it means the commit is still in the repository and is reachable. Then you won't see the past commits in the deployments as they will be in a reachable state. To avoid this behaviour, you could avoid deleting the source branch, as the commit would then meet the aforementioned criteria.