Triggering a custom pipeline for a pull request through the API

[rickard.staaf]

Hello!

Since we cannot queue pipelines in bitbucket, we have created our own queue using Jenkins, and thus we control the pipelines in Bitbucket through the API. Since we do not want the pipeline to trigger automatically, we use a custom pipeline.

It is simple to trigger the custom pipeline for a specific commit, but we want to do it for a pull request. However when trying to post something like this:

{ "target": { 
    "type": "pipeline_pullrequest_target", 
    ... 
    "selector": { "type": "custom", "pattern": "my-custom-pipeline" } 
    }
}

It will actually replace the selector part with { "type": "pull-requests", "pattern": "**" }, so that the wrong pipeline is triggered.

Is there any way of triggering a custom pipeline for a pull request through the API?

/Rickard

[Theodora Boudale]

Hi Rickard,

Custom pipelines can be triggered only for a specific branch or commit, I'm afraid it is not possible to trigger them for a pull request (either via API or via the UI).

Pull request pipelines can only be triggered if you define them with the pull-requests keyword in the bitbucket-pipelines.yml file, and they'll get triggered automatically when opening or updating a PR.

Also, just to clarify the following: pull-requests pipelines work a bit differently than pipelines that run on commits. They merge the destination branch into your working branch before they run (not in the Bitbucket repo, but in the Docker container where the build runs), so then the build runs on the merge commit. Is this also what you'd like to do, by running a custom build on a PR? Or is your use case different?

Kind regards,
Theodora

[rickard.staaf]

Hello Theodora, thanks for the reply, it is as I expected then.

Yes the reason that I want a pull request commit is that I want the merge before running the pipeline functionality. The pipeline in question is a hard quality gate doing cypress e2e testing on our code before we allow it to be merged. Running the tests on the branch itself is a workaround we can live with for now, but ideally it would run on the result of the branch and pull request destination, we will see if we get problems where the tests succeed on the branch but not after being merged.

And the reason for not using a pull-request pipeline is that the e2e tests have to be queued (which there is no support for in Bitbucket) as running several in parallel will break the environment the tests run on, and since Bitbucket cannot queue up pipelines I had to create that queue elsewhere and control the hard quality gates through the API.

[Theodora Boudale]

Hi @rickard.staaf ,

Thank you for your reply and explanation of your use case.

We have a feature request in our issue tracker for the ability to queue non-deployment steps:

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

If you'd be interested in this, I would suggest that you add your vote (by selecting the Vote for this issue link) as the number of votes helps the development team and product managers better understand the demand for new features. You are more than welcome to leave any feedback, and you can also add yourself as a watcher (by selecting the Start watching this issue link) if you'd like to get notified via email on updates. Implementation of new features is done as per our policy here and any updates will be posted in the feature request.

Would you like me to open a feature request for the ability to run custom builds on PRs as well? Please feel free to let me know.

In the meantime, one workaround I can think of would be to create a custom build, where in the script:
- you checkout the source branch
- then you checkout the destination branch of a PR
- then do a merge
- then run your tests

You can define a variable in this custom build for the destination branch, so when you trigger the pipeline, the user gives as input the destination branch.

You can then run these builds in the last commit of the source branch, and the merge will happen when the script is running.

The exact implementation would depend on whether you're merging to the repo's main branch or not.

Would you be interested in this workaround, so I can check on what the script would need to look like? If so, please let me know
- whether you are only creating and merging PRs to the repo's main branch
- or if you're also creating and merging PRs between other branches (with the repo's main branch not included) as well

Kind regards,
Theodora