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

Multiplex Bamboo builds from a subversion commit trigger based on build plan svn path

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

      The concept of triggering a build using a Subversion (or other scm) commit hook is a good one, but from a build plan maintenance standpoint it's not realistic to update the svn commit hook every time a build plan is added, removed, or has its keys changed. So the triggering implementation documented here isn't workable, so we rely on polling and the checkout process is much less efficient than it could be.

      At my company, editing the commit hook requires working with operations; adding/editing a build plan is something an engineer can do.

      It seems the proper way to create a build trigger would be to have the post-commit hook call Bamboo on every commit (or potentially some subset of all commits - that can be scripted). Then Bamboo does a quick check (using svn log) and maps the paths of all the modified files to the build plans in Bamboo using each file's svn path. This creates a candidate list of build plans to trigger as a result of the commit. Of the candidate list, only the build plans that are set to "trigger build when scm changes" would be triggered.

            [BAM-3017] Multiplex Bamboo builds from a subversion commit trigger based on build plan svn path

            Atlassian Update - 27 April 2025

            Hello,

            Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself.

            Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap.

            Please note the comments on this thread are not being monitored.

            You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here.

            To learn more about our recent investments in Bamboo Data Center, please check our public roadmap.

            Kind regards,
            Bamboo Data Center

            Aakrity Tibrewal added a comment - Atlassian Update - 27 April 2025 Hello, Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself. Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years , including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap. Please note the comments on this thread are not being monitored. You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here. To learn more about our recent investments in Bamboo Data Center, please check our public roadmap . Kind regards, Bamboo Data Center

            EddieW added a comment -

            I just found this ticket today, but had the same need myself and wrote a simple plugin to defer all the repo mapping to Bamboo. Just a one-time stateless post-commit file to trigger the logic.
            https://eddiewebb.atlassian.net/wiki/display/TRIG/Alternative+Repository+Triggers+for+Bamboo+Home

            snapshot preview http://maven.edwardawebb.com/repository/snapshots/com/edwardawebb/bamboo-repository-triggers/1.0-SNAPSHOT/bamboo-repository-triggers-1.0-20150110.193805-2.jar

            EddieW added a comment - I just found this ticket today, but had the same need myself and wrote a simple plugin to defer all the repo mapping to Bamboo. Just a one-time stateless post-commit file to trigger the logic. https://eddiewebb.atlassian.net/wiki/display/TRIG/Alternative+Repository+Triggers+for+Bamboo+Home snapshot preview http://maven.edwardawebb.com/repository/snapshots/com/edwardawebb/bamboo-repository-triggers/1.0-SNAPSHOT/bamboo-repository-triggers-1.0-20150110.193805-2.jar

            It'd be really good to have this feature in the standard Bamboo installation as the current solution doesn't work well with a situation when there are many different projects sitting in the same vcs repo (quite typical scenario for SVN)

            Yury Samokhvalov added a comment - It'd be really good to have this feature in the standard Bamboo installation as the current solution doesn't work well with a situation when there are many different projects sitting in the same vcs repo (quite typical scenario for SVN)

            We use one repository per platform, i.e. one for Java and one for .Net
            And we obviously have multiple projects - both in Jira and in Bamboo.
            Ideally we'd like this solution to ensure that Bamboo is notified and then Bamboo works out which project and which plan it should run.

            Bernard O'Flynn added a comment - We use one repository per platform, i.e. one for Java and one for .Net And we obviously have multiple projects - both in Jira and in Bamboo. Ideally we'd like this solution to ensure that Bamboo is notified and then Bamboo works out which project and which plan it should run.

            John Crim added a comment -

            RE externals, presumably svn triggers on external repositories can't trigger Bamboo builds in the intranet. So polling is useful for those (infrequent) cases.

            I don't know about Ivy - how does that help me trigger builds upon svn commits?

            The bottom line IMO is that most organizations use a small number of svn repositories (often 1) for a large number of projects. And commit triggers have the potential to be far more efficient and immediate (and provide predictable build order) than polling, particularly when you have hundreds of build plans. So tying the trigger mechanism to a single build plan is irrational.

            John Crim added a comment - RE externals, presumably svn triggers on external repositories can't trigger Bamboo builds in the intranet. So polling is useful for those (infrequent) cases. I don't know about Ivy - how does that help me trigger builds upon svn commits? The bottom line IMO is that most organizations use a small number of svn repositories (often 1) for a large number of projects. And commit triggers have the potential to be far more efficient and immediate (and provide predictable build order) than polling, particularly when you have hundreds of build plans. So tying the trigger mechanism to a single build plan is irrational.

            Isn't a common pattern in SVN to create a multi-module project directory tree using svn:externals?

            project/src
            /lib/module1->external-repo-path-via-svn:external
            /lib/module2->external-repo-path-via-svn:external

            etc...

            Or use Ivy for dependency management? I think the Feature request is valid but there's certainly existing Project organization patterns that work well with the way Bamboo does things.

            Rene Medellin [Atlassian] added a comment - Isn't a common pattern in SVN to create a multi-module project directory tree using svn:externals? project/src /lib/module1->external-repo-path-via-svn:external /lib/module2->external-repo-path-via-svn:external etc... Or use Ivy for dependency management? I think the Feature request is valid but there's certainly existing Project organization patterns that work well with the way Bamboo does things.

            John Crim added a comment -

            It seems that to do this correctly would require some Bamboo server-side support - eg query for all build plans with an svn path that contains the updated path. For each of those build plans that use the trigger build strategy, trigger them. I'm not Perl savvy, so I can't evaluate whether your script is able to accomplish the equivalent of that on the svn end; but I don't see how it could.

            John Crim added a comment - It seems that to do this correctly would require some Bamboo server-side support - eg query for all build plans with an svn path that contains the updated path. For each of those build plans that use the trigger build strategy, trigger them. I'm not Perl savvy, so I can't evaluate whether your script is able to accomplish the equivalent of that on the svn end; but I don't see how it could.

            rkrzewski added a comment -

            Here's a script I have written for my linux-based installation. It is written in Perl, using libwww-perl library. It should work out the box with simple URL & path customization.
            Repository path to build plan mapping is configured in a simple text file: each line contains a path followed with one or more build plans.
            You can test the script before deploying it invoking it with -d option: debug information will be printed instead of making actual HTTP requests.
            Feel free to use this script if you find it useful.
            As a sole author, I hereby contribute this script to Atlassian, in case they wish to include it in future Bamboo releases.

            rkrzewski added a comment - Here's a script I have written for my linux-based installation. It is written in Perl, using libwww-perl library. It should work out the box with simple URL & path customization. Repository path to build plan mapping is configured in a simple text file: each line contains a path followed with one or more build plans. You can test the script before deploying it invoking it with -d option: debug information will be printed instead of making actual HTTP requests. Feel free to use this script if you find it useful. As a sole author, I hereby contribute this script to Atlassian, in case they wish to include it in future Bamboo releases.

            rkrzewski added a comment -

            At this point repository polling seems to be the only option for any middle or large installation, which is a shame because it results in unnecessary resource utilization, while doing this correctly seems to be quite easy to implement. Also, the new path-based trigger implementation could coexist with existing key based implementation, using different action parameter name.

            There's one thing that needs to be considered: The recommended practice for maven2 projects is embedding child modules in the source tree of their parent module. Because of this the build trigger must deal correctly with overlapping SVN paths. In nested module tree scenario, only the innermost module plan (longest match between modified resource path and plan's source path) should be triggered. However for the sake of flexibility, a global configuration option could be provided for choosing between triggering innermost, outermost, or all matching modules.

            rkrzewski added a comment - At this point repository polling seems to be the only option for any middle or large installation, which is a shame because it results in unnecessary resource utilization, while doing this correctly seems to be quite easy to implement. Also, the new path-based trigger implementation could coexist with existing key based implementation, using different action parameter name. There's one thing that needs to be considered: The recommended practice for maven2 projects is embedding child modules in the source tree of their parent module. Because of this the build trigger must deal correctly with overlapping SVN paths. In nested module tree scenario, only the innermost module plan (longest match between modified resource path and plan's source path) should be triggered. However for the sake of flexibility, a global configuration option could be provided for choosing between triggering innermost, outermost, or all matching modules.

            Also important for us, hudson seems to be more elegant and flexibel here...

            Oliver Nölle added a comment - Also important for us, hudson seems to be more elegant and flexibel here...

              Unassigned Unassigned
              70c0a1fc522b John Crim
              Votes:
              33 Vote for this issue
              Watchers:
              23 Start watching this issue

                Created:
                Updated:
                Resolved: