Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-11205

Support detecting and building forks from Github, Bitbucket Cloud and Bitbucket Server

XMLWordPrintable

    • 3
    • 13

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      from https://answers.atlassian.com/questions/40180/support-github-pull-request-notifications-in-bamboo-to-implement-gated-check-ins

      Bamboo 4.0 will support branch-by-branch workflows in hg/git - the developer can 'fork' the mainline branch into his/her personal branch, work, and ask Bamboo to act as gatekeeper between personal branch and the mainline branch.

      However, some people might want to work by forking the whole repo, commit to that personal repo, and ask Bamboo to act as gatekeeper between the personal repo and the mainline repo. This use-case is more probable in environments where strong policies are enforced (like for example casual developer has no 'push' access to the mainline repo, nor the admin access to the Bamboo).

      note, that it should be possible to achieve the branch-by-fork workflow utilizing Bamboo 4.0 facilities, but it wouldn't be so straight out-of-the-box, and would force the casual developer has admin access to the Bamboo admin. A few things that we should keep in mind if we implement this story:
      * automatic detection of forks (probably not doable outside of Github & Bitbucket)
      * merging the same branch, but on two different repositoryUrls

            [BAM-11205] Support detecting and building forks from Github, Bitbucket Cloud and Bitbucket Server

            Marcin Gardias added a comment - - edited

            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.

            Marcin Gardias added a comment - - edited 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 .

            Jurgis added a comment -

            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. 

            Jurgis added a comment - 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. 

            Cody Briscoe Horton added a comment -

            Any updates/is this on the roadmap?

            Cody Briscoe Horton added a comment - Any updates/is this on the roadmap?

            Marco Baldelli added a comment -

            @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?

            Marco Baldelli added a comment - @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?

            Justin hammond added a comment -

            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

            Justin hammond added a comment - 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

            אופיר שמש added a comment -

            Hey there is an update with that issue ? 

            אופיר שמש added a comment - Hey there is an update with that issue ? 

            Krystian Brazulewicz added a comment -
            Atlassian Update

            Hi everyone,

            Thanks for your interest in this issue.
            This request is considered a potential addition to our longer-term roadmap.

            We'll typically review this request in about 6 months time, at which point we’ll consider whether we need to alter its status.

            For the nearest future we've decided to prioritise other areas of the Bamboo roadmap, including:

            # Performance and stability improvements
            # Providing building blocks for High Availability and Disaster Recovery solutions
            # Improving permission system
            # Allowing per-project allocation of resources
            # Improving Bitbucket Server and Jira integrations

            You can learn more about our approach to highly voted server suggestions here.

            To learn more on how your suggestions are reviewed, see our updated workflow for server feature suggestions.

            Kind regards,
            Bamboo Team

            Krystian Brazulewicz added a comment - Atlassian Update Hi everyone, Thanks for your interest in this issue. This request is considered a potential addition to our longer-term roadmap. We'll typically review this request in about 6 months time, at which point we’ll consider whether we need to alter its status. For the nearest future we've decided to prioritise other areas of the Bamboo roadmap, including: # Performance and stability improvements # Providing building blocks for High Availability and Disaster Recovery solutions # Improving permission system # Allowing per-project allocation of resources # Improving Bitbucket Server and Jira integrations You can learn more about our  approach to highly voted server suggestions here . To learn more on how your suggestions are reviewed, see our updated workflow for server feature suggestions . Kind regards, Bamboo Team

            Tobin Richard added a comment -

            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.

            Tobin Richard added a comment - 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.

            roman_breuer_hta added a comment -

            +1

            roman_breuer_hta added a comment - +1

            Ashley Camba added a comment -

            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. :/

            Ashley Camba added a comment - 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. :/

              851f15845f55 Mateusz Szmal
              pstefaniak PiotrA
              Votes:
              219 Vote for this issue
              Watchers:
              127 Start watching this issue

                Created:
                Updated:
                Resolved: