The feature to detect and build pull requests from forks of Bitbucket Cloud and Bitbucket Server repositories has been added in Bamboo 8.2 release.

As for Github, we've opened a new feature request regarding extending this functionality here: https://jira.atlassian.com/browse/BAM-21710.

Any updates on this task? Feature would solve many problems for clients - as we see based on many comments/votes in this and duplicated tasks. 

Any updates/is this on the roadmap?

@Justin Hammond
I'm running a few tests using the endpoint you provided and, like you said, it works well also with the commit status check.

One thing I'm noticing though: all the Plan Branches (which are actually PRs) are disabled some time after their creation and on the logs I see

[ChainBranchManagerImpl] Marking VCS branch refs/pull/18/head of chain branch GH-TSMP34 as removed because its name matches refs/pull/18/head
[ChainBranchManagerImpl] Chain branch GH-TSMP34 was disabled because its VCS branch was deleted
[ImmutablePlanCacheServiceImpl] Invalidating GH-TSMP34

When I check on the GH Webhook history I see no other push rather than "PR opened" but somehow Bamboo decides to disable the Plan Branch.

Did you experience this kind of problem?

I found a way thats pretty simple. The rest API of Bamboo allows you to specify the vcsBranch. So sending a PUT request to this Bamboo URL triggers a Bamboo to create a new branch and start a build:

/rest/api/latest/plan/OZW-PRTST/branch/' + pr + '.json?vcsBranch=refs/pull/' + pr + '/head'

Where "pr" is the Pull Request Number.

I have written a simple OpenFAAS function to take a GitHub Pull Request WebHook and Trigger Bamboo to build the PR here: https://github.com/Fishwaldo/faas-bamboo-pr-trigger

You will need to modify the hostname in bamboo-pr-trigger/handler.js and setup bamboo-username and bamboo-password secrets on your openFAAS server and combined with a updated bamboo-github-status addon it works nicely (see my fork here: https://github.com/Fishwaldo/bamboo-github-status )

See here for a real life demo:

https://github.com/OpenZWave/open-zwave/pull/1817

Repeating a comment I left on the related issue: very disappointing to see this is still broken.

Bamboo should be an easy sell internally for us since we're already using Bitbucket, Jira, and Confluence but it's unworkable for us until this is fixed.

The best option still appears to be Jenkins.

+1

We are currently using the Atlassian in three companies I have been involved in, except for Bamboo, and this ticket is pretty much the main showstopper. Now that we are deciding on the development stack, it looks like it's going to be teamcity with crowd integration again. Our CI tool shouldn't determine our release workflow. :/

Not being able to edit the above comment, the link wasn’t correct to the community request.  The correct link: Bamboo build on new get tag

Note that this feature would, I believe, also address a community request to build on a new git tag that has been active for over 5 years

+1, this is a fairly standard practice and should be a Bamboo feature.

We are currently using bamboo and are strongly considering other CI/CD toolsets because of this missing functionality. It makes working with forks hackish and hard to support/troubleshoot. I would argue its easier to get another system to talk to JIRA that it is to get bamboo to do the right thing for forks and have it show the data properly.

This is a serious show stopper for us. We use the whole Atlassian build tool chain, except bamboo. We want to migrate to bamboo from jenkins to have better integration with JIRA and Bitbucket. We have the feeling that bamboo scales better as well which is a real issue with our 50+ repositories.

Thanks to Bitbucket, working with Pull Requests has become our way to work, review, contribute etc. Being unable to take advantage of that with bamboo is really hard to understand. Hope you can soon give some outlook to that feature.

+1

+1

As everybody, I really need en easy way for bamboo to detect PR from github in its core.

Are there any updates as to when this might actually get some traction? this is greatly impacting our workflow as well

Yes, that's just hilarious. I fell in love with the gitflow+prbuilders combination (with Jenkins), and right now I can't believe I could develop without it. Hell, I even tried to build a plugin to handle this with Bamboo, but the documentation is so insanely outdated that I can't manage to make it work (still listing classes deprecated in version 2.7, guys...) Too bad this is such low priority.

Must agree with Kjetil. Atlassian has this awesome documentation but you can't use this model with Bamboo.

Hi,

In my humble opinion the lack of this feature prevents your users from using a forking model. This again limits our workflow and how we can do gatekeeping.

This is also the GitHub workflow, and it is a workflow people have come to love, when working with source code on GitHub.

Please focus on this!

Hi,

I just wanted to provide an update on this request. At this stage it's unlikely that we'll address it before the end of the year.

Thanks everyone for your feedback, please know that we read it and take it into account when prioritising our roadmap but due to other factors we are unable to put this development on top of the backlog.

Thanks,

Sten Pittet
Bamboo Product Manager

This would allow the main repository to disallow forced pushes while allowing developers to force push to their forks. In other words, it would be safer, but developers could still clean up their branches easily before merging.

Currently, rebasing and squashing commits on a branch in the main repository (which disallows forced pushes) requires me to:

1. git rebase -i
2. Decline the current pull request
3. Delete the feature branch from Stash
4. Push the updated feature branch to Stash
5. Create a new pull request
6. Get approvals (again), post link to old pull request (which had comments on it), etc.

A lot of the conversation around this feature has happened near the version 4 release of Bamboo. Now we're well into version 5, perhaps it's time to revisit this possibility?

Surprised this ticket is really 3 years old. Slickdeals.net wants this!

For at Grainger, not having suppport to treat Fork/Pull Requests as first class citizens is a showstopper for using Bamboo. We moved away from using Feature brances for CI, and found much better support with Fork/PR approach. We have some of this working with Jenkins, but we would've enjoyed better integration with Jira if Bamboo would support this. So I guess we'll hold off on Bamboo until this feature is available, or start looking at other alternatives.