-
Suggestion
-
Resolution: Unresolved
-
7
-
Recently we have been given the option of defining pipelines that only run on pull requests.
This is great, but the current way of filtering relevant commits by the name of the branch being PR'ed from is only covering part of the need.
I suggest a feature that lets you run pull-request triggered pipelines based on destination branch name.
Example use case
A test taking a few hours might not be desirable for every PR (they got smaller tests of cause), but must always be performed before a merge into the master branch.
Ideas for implementation
Similar to
#!yaml
pipelines:
pull-requests:
There will be a
#!yaml
pipelines:
pull-requests-to:
master:
Indicating that it is now the name of the destination branch that filters whether the steps are initiated.
Another way to solve this could be to add syntax sugar to the name of the existing pipeline setup - for example, by prepending with => to indicate that the following is the name of the destination branch of the PR
#!yaml
pipelines:
pull-requests:
'=> master':
[BCLOUD-17859] Pull-request for pipeline based on destination branch
I'm excited to announce that you can now use Flowie to trigger Bitbucket pipelines, using the Smart pipelines plugin. Among other features, this plugin lets you target pull requests based on the destination branch and other aspects of the PR, including labels. It's in EAP, if you're interested, please try it out and give us feedback at support@flowie.app.
Flowie can be installed via Atlassian marketplace or our website.
I just spent some time investigating why my PRs are not trigering builds on PRs.
At some point I decided I need to google it and I have never would have suspected that this is source branch and not target branch.
I understand that some people might differentiate their runs on source branch, but at least in my experience it is much more common to differentiate on target branch.
This sounds like a must have feature to me and I am very surprised it is not implemented.
+1
My team are considering to switch from GitLab to Bitbucket, this feature will help us to create more clean step code in workflow like GitLab flow.
For example
- merge request/merge commit from features to main branch for testing and build docker image
- merge request/merge commit from main to uat branch for deploy to uat environment and
- merge request/merge commit from uat to production branch for deploy to production environment
Currently I've add Checking PR destination branch as @Lorenzo explained to all steps in pull request pipeline. At this point I can say that GitLab has more powerful pipeline control logic using workflow and rules.
I guess destination branch doesn't matter if you only have one destination branch; master.
Join the world of puristic CI, there's only master branch, and every merge to it causes a test that checks the whole code and initiates a prod deploy if passes.
How good is your testing folks? Because that's the future, and Bitbucket is helping us to do the jump.
No pre releases no stagings no developer environments.... and as a bonus, we can skip integration testing.. how much money will that save us?
You see, win win... can't understand the complains 
Over 5 years since this feature request was created, i have no idea if Atlassian uses it's own pipelines mechanism, but this is like a basic gated check to be able to run your pull-request against your main target branch (master/main etc.). For example, longer integration tests should run only before merging to main branch.
Maintaining hacky scripts in order to do BASIC platform work is not the way IMHO.
Gotta say, I'm new to devops stuff, and I'm kind of shocked that this isn't already a thing. Let alone the fact that this issue is a week away from its 5-year anniversary of waiting. What gives Atlassian? As @robjohnson pointed out: this is what PRs are FOR. You want to create a build and run testing so that reviewers can see if your code broke things so they know if it should be included in this branch. In what world is a PR concerned with the source branch: PRs are designed to protect a destination branch.
How about fixing this, hmm?
C'mon, we are all waiting for this 
so far i'm using this kind of logic to avoid running the whole pipeline, but it's ugly and has to be copy pasted everywhere
...
pull-requests:
"**":
- step:
name: Checking PR destination branch
script:
- if [ "$BITBUCKET_BRANCH" == "dev" ] || [ "$BITBUCKET_BRANCH" == "main" ] || [ "$BITBUCKET_BRANCH" == "master" ] || [ "$BITBUCKET_BRANCH" == "hotfix" ] || [ "$BITBUCKET_BRANCH" == "release" ]; then printf 'Not a target branch we want to check'; exit; fi
Since this is has been "IN_PROGRESS" for more than a year with 57465700c4e1 , is there maybe any news on the status on this suggestion?
Several workarounds mention that a variable "BITBUCKET_PR_DESTINATION_BRANCH" can be used to check the target, but apparently on Bitbucket cloud this is not available, only BITBUCKET_BRANCH.