Using sgd:source:delta doesn't calculate correct diff in PullRequest

Question

I'm trying to setup CICD pipeline to validate code changes before deployment to next environment.

My pipeline is triggered when PR is created,

here is a part of pipeline that i need to fix. In particular, this line doen't work as expected:

- sf sgd:source:delta -f HEAD^ --output . -i .gitignore

It works fine, if in PullRequest there is one commit, and it identifies only the last commit changes.
However, it should identify the whole diff between source and target branch.
This worked on Azure pipeline and here in bitbucket it's not.

I tried different ways, and I'm stuck

pull-requests:
'**':
      - step:
name: Install Salesforce CLI (new) and sfdx-scanner plugin. Decrypt server key and auth to org
deployment: nirvana
script:
            - echo "Running Validation to Nirvana"
#Install SF CLI and Scanner
            - npm install --global @salesforce/cli
#            - sf plugins install @salesforce/sfdx-scanner
            - echo "show username"  $USERNAME
#Decrypt server key
            - openssl enc -nosalt -aes-256-cbc -d -in assets/server.key.enc -out assets/server.key -base64 -K $DECRYPTION_KEY -iv $DECRYPTION_IV
# Auth to Nirvana
            - sf org login jwt --username $USERNAME --jwt-key-file assets/server.key --client-id $CONSUMER_KEY --instance-url $INSTANCE_URL
#Installing sfdx-git-delta plugin
            - echo 'y' |  sf plugins:install sfdx-git-delta
# Checking for delta changes
            - sf sgd:source:delta -f HEAD^ --output . -i .gitignore
#Showing the generated delta of package.xml
            - cat package/package.xml
#Showing the destructiveChanges.xml
            - cat destructiveChanges/destructiveChanges.xml
#Running validation on source code
            - sf project deploy start --ignore-warnings --manifest package/package.xml --dry-run --test-level RunLocalTests --target-org $USERNAME --post-destructive-changes destructiveChanges/destructiveChanges.xml --wait 40

Theodora Boudale · Answer

Hi Anastasia,

I'm not familiar with the tool you are using and I can't offer advice regarding how it should be configured. However, I can explain how the clone works in pull-requests builds in pipelines, since the issue seems to be related to the argument HEAD^ you provide.

Let's assume that you create a pull request from develop branch to main branch and a pull-requests build gets triggered.

* A Docker container starts for each step
* Branch develop gets cloned in this container
* The last commit of main branch gets merged into develop

All this happens during Build setup, and you can see it if you expand the Build setup section of the build log on our website. Then, the commands of the step's script get executed, and when the step is finished the Docker container gets destroyed.

In that clone:

* HEAD is the merge commit that was created during the Build setup
* HEAD^ is the latest commit of develop when the build was triggered.
* HEAD^2 is the latest commit of main when the build was triggered.

I hope this info is useful in understanding the state of the clone where the pipeline runs. For advice specific to the tool you are using, it may be best to reach out to the support team of this tool.

You could also use the following guide to debug your build locally until you have a build that works, before making any changes to the Bitbucket repo (this way you don't consume build minutes while debugging):

* https://confluence.atlassian.com/bbkb/troubleshoot-failed-bitbucket-pipelines-locally-with-docker-1318882094.html

Kind regards,
Theodora