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

Allow new build directories per plan to be created in /xml-data/build-dir

    • Icon: Suggestion Suggestion
    • Resolution: Obsolete
    • None
    • Builds
    • None
    • 2
    • 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.

      While we've been enjoying the features of Bamboo, there's a few issues that are hard to resolve. One of there is the methodology with the file layout structure of builds.

      For a plan, say 'TRUNK' on projects MyProject1, MyProject2, Bamboo makes a directory in /xml-data/build-dir called 'MYPROJECT1-TRUNK' and 'MYPROJECT2-TRUNK'.

      If I make another plan, say 'BRANCH' on projects MyProject1, MyProject2, Bamboo makes a directory in /xml-data/build-dir called 'MYPROJECT1-BRANCH and 'MYPROJECT2-BRANCH'.

      The trouble with this (for us) lies in two areas:

      1.) Dependency builds between different ant project projects expect the project name to be what the SVN module is called, i.e. MyProject1. This allows for build artifacts from MyProject1 to be fetched by MyProject2 by navigating the directory structure appropriately, i.e. Project2 gets artifacts in ../MyProject1/dist

      We currently work around this issue by manually creating symbolic links in that /xml-data/build-dir directory, i.e. 'ln -s MYPROJECT1-TRUNK MyProject'

      2.) Having build plans based on source control branches in the same directory causes collisions for trying to get appropriate build artifacts. In the example above, I explained how we can work around the renaming of the projects by using symbolic links so that ant can navigate the directory path to fetch its dependencies. However, this model fails if we are trying to have two projects with the same SVN name but from the trunk and a branch in the same directory – the symbolic link would always have to map only to a single project.

      While we haven't done it yet, I suppose the workaround would be to run a second instance of Bamboo on the same JBoss server and give it a different bamboo_home directory.

      What might be nice (from our perspective, of course) is the option or ability to say to use the 'native project names' for the builds which could then maybe map out a driectory structure like:

      xml-data/build-dir

      – TRUNK
      — MyProject1
      — MyProject2
      --BRANCH
      — MyProject1
      — MyProject2

      whereas MyProject1 and MyProject2 are the 'native svn project names' and TRUNK and BRANCH are Bamboo plans.

            [BAM-904] Allow new build directories per plan to be created in /xml-data/build-dir

            AntonA added a comment -

            In Bamboo 3.0 it will be possible to configure Bamboo to pass artifacts from one job to another. This should solve the problem of trying to use an artifact after it is built in another build.

            Bamboo 3.0 should be shipped in February 2011.

            As mentioned previously, svn externals can also be used to make it work with Bamboo versions before 3.0.

            Due to this I will resolve this issue.

            Please add a comment here if I am misunderstanding something and passing artifacts between jobs does not help.

            AntonA added a comment - In Bamboo 3.0 it will be possible to configure Bamboo to pass artifacts from one job to another. This should solve the problem of trying to use an artifact after it is built in another build. Bamboo 3.0 should be shipped in February 2011. As mentioned previously, svn externals can also be used to make it work with Bamboo versions before 3.0. Due to this I will resolve this issue. Please add a comment here if I am misunderstanding something and passing artifacts between jobs does not help.

            this is a pretty big issue for us. do you have any idea if a fix for this will make it into a release in the near future? My workaround in BAM-1369 might be a way to approach this problem.

            Dennis Ryan added a comment - this is a pretty big issue for us. do you have any idea if a fix for this will make it into a release in the near future? My workaround in BAM-1369 might be a way to approach this problem.

            edwin added a comment -

            Hi Michael,

            Firstly, many thanks for supporting Bamboo.

            Secondly, with regards to multiple repository locations - what I am thinking is that Bamboo will probably keep the folder name of your svn module. In your case, I am thinking that you will have a set up like this:

            • Your instance can have one Bamboo Project - (we can give this a key, say.. PROJ - note that this is not the same as the 'native svn project names' - it's at a broader conceptual level)
            • You then setup two Build Plans under this project - (TRUNK, and BRANCH).
            • You then have two repository locations under each build plan: (MyProject1, and MyProject2).

            Then, what the file structure probably looks like is something like this:
            /xml-data/build-dir/PROJ-TRUNK/MyProject1
            /xml-data/build-dir/PROJ-TRUNK/MyProject2
            /xml-data/build-dir/PROJ-BRANCH/MyProject1
            /xml-data/build-dir/PROJ-BRANCH/MyProject2

            I believe a setup like this should be able to resolve the issue you are currently experiencing?

            Regarding running multiple copies - unfortunately, a copy of the Bamboo license only entitles you to one instance of the software (please see http://www.atlassian.com/software/bamboo/pricing.jsp#commercial).

            Lastly - with regards to the challenge you are currently facing - I would recommend that you give subversion externals (http://svnbook.red-bean.com/en/1.0/ch07s03.html) a try in the short term. As an example, you can create two new "empty" "projects" in subversion: e.g. project-trunk and project-branch. Within each, you can then specify MyProject1 and MyProject2 as "externals" - this has been an approach used by others to set up plans which required multiple repositories (please see BAM-882). The only drawback of this is fisheye integration, which currently will not work for the external modules.

            I hope this has helped.

            Regards,
            Edwin

            edwin added a comment - Hi Michael, Firstly, many thanks for supporting Bamboo. Secondly, with regards to multiple repository locations - what I am thinking is that Bamboo will probably keep the folder name of your svn module. In your case, I am thinking that you will have a set up like this: Your instance can have one Bamboo Project - (we can give this a key, say.. PROJ - note that this is not the same as the 'native svn project names' - it's at a broader conceptual level) You then setup two Build Plans under this project - (TRUNK, and BRANCH). You then have two repository locations under each build plan: (MyProject1, and MyProject2). Then, what the file structure probably looks like is something like this: /xml-data/build-dir/PROJ-TRUNK/MyProject1 /xml-data/build-dir/PROJ-TRUNK/MyProject2 /xml-data/build-dir/PROJ-BRANCH/MyProject1 /xml-data/build-dir/PROJ-BRANCH/MyProject2 I believe a setup like this should be able to resolve the issue you are currently experiencing? Regarding running multiple copies - unfortunately, a copy of the Bamboo license only entitles you to one instance of the software (please see http://www.atlassian.com/software/bamboo/pricing.jsp#commercial ). Lastly - with regards to the challenge you are currently facing - I would recommend that you give subversion externals ( http://svnbook.red-bean.com/en/1.0/ch07s03.html ) a try in the short term. As an example, you can create two new "empty" "projects" in subversion: e.g. project-trunk and project-branch. Within each, you can then specify MyProject1 and MyProject2 as "externals" - this has been an approach used by others to set up plans which required multiple repositories (please see BAM-882 ). The only drawback of this is fisheye integration, which currently will not work for the external modules. I hope this has helped. Regards, Edwin

            Please note, having different repository locations would NOT help because Bamboo still renames directories on us. I have to make symbolic links to map the directories so things work.

            Is this going to be scheduled for a fix?

            We bought a licensed copy of Bamboo. Does that allow us to run multiple copies of it? The only way I can think of, short term, to get around this is to have multiple versions of Bamboo running in different JBoss instances (or whatever, we just happen to throw it into the jboss app server) AND set the Bamboo home to be something different.

            Michael Dinsmore added a comment - Please note, having different repository locations would NOT help because Bamboo still renames directories on us. I have to make symbolic links to map the directories so things work. Is this going to be scheduled for a fix? We bought a licensed copy of Bamboo. Does that allow us to run multiple copies of it? The only way I can think of, short term, to get around this is to have multiple versions of Bamboo running in different JBoss instances (or whatever, we just happen to throw it into the jboss app server) AND set the Bamboo home to be something different.

            By the way, we just got our [paid] Bamboo license, if that makes any difference.

            Michael Dinsmore added a comment - By the way, we just got our [paid] Bamboo license, if that makes any difference.

            That would help some, but it would also be nice to not have to manually create all these symbolic links for the projects so that it can traverse and find its things easily.

            I suppose we could fix that if we had Ivy publish its artifacts to a repository instead of fetching them locally....

            Michael Dinsmore added a comment - That would help some, but it would also be nice to not have to manually create all these symbolic links for the projects so that it can traverse and find its things easily. I suppose we could fix that if we had Ivy publish its artifacts to a repository instead of fetching them locally....

            MarkC added a comment -

            Guys,

            I've linked to the related issue.

            I think this issue would be fixed if you can specify multiple, different repository definitions.

            Cheers,

            Mark C

            MarkC added a comment - Guys, I've linked to the related issue. I think this issue would be fixed if you can specify multiple, different repository definitions. Cheers, Mark C

            Is it possible to specify a different build directory for each plan? maybe in a secret xml file

            Dennis Ryan added a comment - Is it possible to specify a different build directory for each plan? maybe in a secret xml file

              Unassigned Unassigned
              62a3857466cd Michael Dinsmore
              Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: