Bitbucket get PR ID during merge pipeline

[Vikash Balasubramanian]

Say I have a bitbucket pipeline that runs on every PR and builds a docker image and tags it with `BITBUCKET_PR_ID` https://support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets/ and pushes it to AWS ECR.

In our workflow we want to merge only when the PR build is successful. So when we do the merge instead of rebuilding the Docker image, we would like to reuse the Docker image produced by the successful build. How do we get the `BITBUCKET_PR_ID` for a build that triggers when merged to master?

What's the correct way of doing this. The Docs say `BITBUCKET_PR_ID` is only accessible in a PR triggered build, so it won't be available during merge. I am open to using any other variable/id other than `BITBUCKET_PR_ID` as long as we can identify the Docker image when we merge the PR. Every merge will be associated with a unique PR so I want to get the association so I can use it to tag an image.

[Patrik S]

Hello @Vikash Balasubramanian ,

Welcome to Atlassian Community.

Unfortunately, as you have mentioned, the BITBUCKET_PR_ID is only available for builds that run for the "pull-request" trigger, which is not the case for a merge, which will run the "branch" triggered pipeline you have configured.

We understand that being able to identify the PR ID in the merge build by using the env variable  BITBUCKET_PR_ID would be great for your use-case, and we already have a feature request for that, which you can find in the following link :

• https://jira.atlassian.com/browse/BCLOUD-20888

I would suggest you to add your vote there, since this helps both developers and product managers to understand the interest. Also, make sure you add yourself as a watcher in case you want to receive first-hand updates from that ticket. Please note that all features are implemented with this policy in mind.

As a workaround until that feature is not implemented, during the execution of your PR build you could create a file named, for example, pr_id.txt containing the value of the environment variable BITBUCKET_PR_ID , and commit and push it back to the branch where the PR build is running, like the example below :

pipelines:
  pull-requests:
    '**': 
      - step:
          script:
            - echo $BITBUCKET_PR_ID > pr_id.txt
            - git add pr_id.txt && git commit -m "[skip ci] updated PR ID" && git push

Pipeline will automatically authenticate the git commands for you, using the token it gets during the build setup. Also, the [skip ci] flag is necessary to not trigger a second build because of the commit being pushed.

Then, when you merge your code to master, you can have your pipeline script use the content of the file previously created (pr_id.txt) to get the PR ID that triggered that merge build.

Hope that helps. Let us know in case you have any further questions.

Thank you, @Vikash Balasubramanian 

Kind regards,

Patrik S.

[Vikash Balasubramanian]

@Patrik Sthis seems like a decent workaround. But is this safe, how will this work when say someone for example updates the PR when the build is running?

Is there a foolproof way to handle such cases?

[Patrik S]

Hey @Vikash Balasubramanian ,

Pipeline builds runs against a specific commit.

In case someone updates the PR while a build is still running, a new build will be triggered which will create a new commit updating the pr_id.txt file. Since they are both running for the same PR, the PR_ID will be the same, so I don't see an issue of both build updating the same file as the value will be equal.

Would you please elaborate on what scenario you think could be unsafe for the workaround ?

Thank you, @Vikash Balasubramanian .

Kind regards,

Patrik S

[Vikash Balasubramanian]

@Patrik S  The issue I was thinking was that, when two builds run in parallel, they don't know about each other.

So when someone updates the PR and another build triggers in parallel, shouldn't there be a git pull and then git commit because otherwise the history of the PR commits will diverge

For example let the top commit of PR be C build 1 adds a commit D and makes it C-> D, build 2 adds a commit E and tries to make it C -> E (because it doesn't know about D) ?

[Patrik S]

Hello @Vikash Balasubramanian ,

Thank you for providing additional context.

Indeed the situation you have reported would cause the push to fail. Also, thinking more about the workaround of creating a commit with the PR ID, I could also identify possible issues with that approach since we are committing to a detached HEAD (pipelines do a hard reset in build setup), and if someone ends up committing  to the source branch at the same time a pipeline is running , it could mess with the repository history. I could not really think of a workaround for that.

However, after further investigating, I think you would have some additional options :

- In case you are using merge commit, use the Bitbucket API to get the ID of the Pull Request where the merge commit was reviewed. The below API endpoint will list all the pull requests where a commit was reviewed :

https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}/pullrequests

The commit ID on the URL can be fetched from the pipelines environment variable $BITBUCKET_COMMIT

Reference : https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pullrequests/#api-repositories-workspace-repo-slug-commit-commit-pullrequests-get

Since the merge commit can only be sourced from a single pull request, it should return just one PR ID. You can then get the PR ID from the JSON returned from the API using a json processor like jq. To identify if a commit is a merge, so you know when to do the API call, you can refer to this thread on stack overflow.

- Another option would be for you to save the PR ID information in the commit message of the PR merge. You can then find out the PR ID# using the git show command:

git show $BITBUCKET_COMMIT

It's required that you treat the git show output correctly to get the PR ID exactly, using a tool like grep.

Hope the above suggestions can help. Let me know if you have any further questions.

Thank you, @Vikash Balasubramanian 

Kind regards

Patrik S

[Vikash Balasubramanian]

deleted