Purpose

This Knowledge Base article aims to provide a solution to enable the "Minimum number of successful builds" merge check to pass successfully when the [skip ci] or [ci skip] label is integrated into the commit message. This is a part of the Continuous Integration/Continuous Delivery (CI/CD) workflow. 

This specific workflow is frequently observed when versioning is incorporated into the CI/CD process.

Environment

A repository environment where the following applies:

• The destination branch in the repository has at least these two restrictions applied: 
    Minimum number of successful builds for the last commit with no failed builds and no in-progress builds (1 or more) 
    No unresolved pull request tasks
• As part of your CI/CD workflow, the last commit before a pull request merge contains the [skip ci]/[ci skip] commit message label to avoid triggering a build
• The [skip ci] commit is added within pipelines as part of the deployment process and is not added by other means (Example: manual commit, pull request sync)
• Unable to perform a merge, as the merge check for successful builds is not considered satisfied (because no build is triggered due to the aforementioned commit message label)

Solution for Pipelines

To rectify this problem using Pipelines, please follow the process below to add a [skip ci] commit to the repository within Pipelines and then update the build status for that commit with the aforementioned [skip ci] or [ci skip] label in order to satisfy the pull request branch restriction and have it considered as a successful build:

1) Create a bash script (.sh file) with a descriptive filename somewhere in the repository with the following contents - this bash script is responsible for updating the build status for the latest commit to SUCCESSFUL:

echo "$BITBUCKET_EXIT_CODE"
if [ "$BITBUCKET_EXIT_CODE" -eq "0" ]; then
echo $BITBUCKET_PIPELINE_UUID

LAST_COMMIT=$(git rev-parse HEAD)
PIPELINES_BUILD_URL="https://bitbucket.org/${BITBUCKET_REPO_FULL_NAME}/pipelines/results/${BITBUCKET_BUILD_NUMBER}"
NAME="Generated from Pipelines build #${BITBUCKET_BUILD_NUMBER}"

curl -X POST -k -H "Content-Type: application/json; charset=utf-8" -H "Authorization: Bearer $BB_AUTH" --data "{\"type\": \"build\", \"key\": \"$BITBUCKET_BUILD_NUMBER\", \"state\": \"SUCCESSFUL\", \"name\": \"$NAME\", \"url\": \"$PIPELINES_BUILD_URL\", \"description\": \"Generated from Pipelines\"}" "https://api.bitbucket.org/2.0/repositories/$BITBUCKET_REPO_FULL_NAME/commit/$LAST_COMMIT/statuses/build"
else
echo "Build failed"
fi

2) Create a repository access token with the following scopes configured and copy its contents somewhere (as this cannot be retrieved later):
Repositories - ADMIN
Pull requests - WRITE
Webhooks - READ/WRITE
  

3) Store this access token by creating a repository variable and storing the access token here so that it may be referenced later:
Name: BB_AUTH
Value: Paste the token you copied earlier
Secured: Yes

4) Combine all of the above elements together within the bitbucket-pipelines.yml script with an after-script tag added to the end of the build step. This is so that it can pass the variable BITBUCKET_EXIT_CODE to the status-update.sh script and if the build is successful, it will update the last commit's (with the skip ci) build status.

NOTE: Please replace the placeholder path/script name below with actual values:

        "branchname/*": 
      - step:
          name: Versioning
          script:
            - // Add [skip ci] commit to repository here, either manually or via a script
          after-script:
            - chmod +x ./filepath/status-update.sh
            - ./filepath/status-update.sh $BITBUCKET_EXIT_CODE  

Once the steps outlined above are completed, verify the solution's functionality. This can be done by initiating the defined step from earlier. This should prompt the creation of a new [skip ci] commit within the repository's script section. Subsequently, the build status should be updated in the after-script section to satisfy the merge check requirements. 

Please make sure to continually monitor this process to ensure that all steps are being carried out correctly and efficiently. Should there be any issues, revisit the steps to identify and rectify any potential errors.

Solution for Non-Pipelines

If performing a manual commit outside of pipelines with [skip ci] as the commit message (for example via repository push or PR merge sync), the commit status needs to be manually updated. This is because it will not be able to automate any kind of build status updates for a [skip ci] commit as by nature, these will never trigger builds on their own.

This can be handled in one of two ways:

1. Modify the bash script provided above and replace the placeholder variable values with actual values necessary to update the build status for the commit and execute it locally.
2. Perform a manual API call using cURL by referring to our API documentation to update the build status for the commit, this is the same as step 1 but requires more manual configuration.