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

Set a default build strategy for new plan branches

XMLWordPrintable

    • 0

    • 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.

      With plans like https://confluence-bamboo.atlassian.com/browse/CONFFUNC-MAIN, which is our first plan to run the acceptance and unit tests, we face the problem that the branch plans created by the automatic branch creation feature inherit the polling interval of their master/template. I'd like to argue that the branch builds could do with a lower polling interval, as the development flow for them is often to ignore the build failures on an early stage of the issue development and care about them once they want to merge upstream. In order to cope with that, I'd like to be able to set or multiply the inherited polling interval for automatic branch (config/plan) creation.

        1. 2012-08-23-181035_929x779_scrot.png
          108 kB
          PiotrA
        2. Screenshot 2020-03-24 at 16.44.47.png
          40 kB
          Marcin Gardias

            [BAM-12089] Set a default build strategy for new plan branches

            Marcin Gardias added a comment -

            This is supported for some time now:

            Marcin Gardias added a comment - This is supported for some time now:

            PiotrA added a comment -

            I see - that makes sense to me. Thanks for explanations.

            PiotrA added a comment - I see - that makes sense to me. Thanks for explanations.

            fabs (Inactive) added a comment - - edited

            Hi, sorry for the confusion. The problem is the high rate of idd branches that get pushed to our canonical repository combined with having automatic branch configuration active on the main plan which is the root of the chain (thus using polling). We try to reduce the contention on CBAC, thus one measure (the better one) is what ratkins suggested in BAM-12071 , but I'd also like to argue that these short-lived idd branches don't need such a high polling interval. Reducing that will probably have not much effect, only on branches where several people are working on and thus push more often to avoid merge conflicts / base on eachother's work. But in general I'd think we should provide a transformation mechanism from the original/master/template plan config to the actual branch plan config, thus I'd think if we solve BAM-12071 it's easy to solve this feature as well. Manual override is not enough imo, since there are many new branches created on a daily bases and I don't want to chase that up. Of course I can write a script for that, and will do in case this request gets rejected, just wanted to ask for it first.

            fabs (Inactive) added a comment - - edited Hi, sorry for the confusion. The problem is the high rate of idd branches that get pushed to our canonical repository combined with having automatic branch configuration active on the main plan which is the root of the chain (thus using polling). We try to reduce the contention on CBAC, thus one measure (the better one) is what ratkins suggested in BAM-12071 , but I'd also like to argue that these short-lived idd branches don't need such a high polling interval. Reducing that will probably have not much effect, only on branches where several people are working on and thus push more often to avoid merge conflicts / base on eachother's work. But in general I'd think we should provide a transformation mechanism from the original/master/template plan config to the actual branch plan config, thus I'd think if we solve BAM-12071 it's easy to solve this feature as well. Manual override is not enough imo, since there are many new branches created on a daily bases and I don't want to chase that up. Of course I can write a script for that, and will do in case this request gets rejected, just wanted to ask for it first.

            James Dumay added a comment -

            bmccoy@atlassian.com similar to how we provide defaults to the merging strategy?

            James Dumay added a comment - bmccoy@atlassian.com similar to how we provide defaults to the merging strategy?

            PiotrA added a comment -

            So manual override is not enough for his case? https://jira.atlassian.com/secure/attachment/70237/2012-08-23-181035_929x779_scrot.png

            PiotrA added a comment - So manual override is not enough for his case? https://jira.atlassian.com/secure/attachment/70237/2012-08-23-181035_929x779_scrot.png

            bmccoy added a comment -

            Talking to Fabian, it seems he wants a system wide configuration option that applies to all branches from all plans. I.e. rules defining how all branches get copied from their various masters.

            bmccoy added a comment - Talking to Fabian, it seems he wants a system wide configuration option that applies to all branches from all plans. I.e. rules defining how all branches get copied from their various masters.

              Unassigned Unassigned
              fakraemer fabs (Inactive)
              Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: