Unfortunately the junit results parser doesn't work outside the jobs working directory, is that true?

Yes, thats our intention. Before doing the update we delete all unversioned or modified files. A normal clean checkout takes up to 40 minutes, this way we get a "clean checkout" within less than 3 minutes!

Hi Maximilian,

Are you aware that the next time the build runs that Bamboo just updates to the latest revision without doing a checkout?

Thanks
James

Thx James for the answer. Unfortunately we have so many different Jobs in the meantime, if all of them would checkout all the time bamboo would be way too slow. So we want to keep the checkout there which then would result in gigabytes of (unnecessary) source code.

Our workaround at the moment is to checkout to ${bamboo.shared.directory} which is a relative path (../shared). In this directory we keep different subversion or git checkouts which is exactly what we expect.

Cheers,
Max

Hi Maximilian,

We have no plans to allow people to checkout outside of the build working directory using Bamboo. If you wish you can call Subversion, Git, Perforce or other tools from a Script task to achieve this.

Thanks
James

@Carl : Now you can't do that anymore, its "forbidden" in Bamboo 4.3.x. Any news on this issue? I tried to checkout to an absolut path with works in windows but in linux it just assumes you would like to add everything to the current path duh!

Unfortunately, it will take some effort to implement as there are concurrency issues that will have to be very carefully managed.

Stages do solve the concurrency problem.

However, I believe being able to pass artifacts from one job to another, as will be possible with Bamboo 3.0, will be the ultimate solution, as it is "clean", easy to understand and manage, and allows for better concurrency if one artifact is consumed by multiple jobs at once (e.g. for testing in different environment).

Cheers,
Anton

Well, using multiple builders sure helps a good bit too. However, I still think this issue would be good to implement, as an option, if not too much effort is required.

I found the "Working Subdirectory" parameter of the builder to do the trick though. Using relative paths with parent folder "..", I managed to get multiple stages to build in the same directory, although they all create their own "dummy" folder anyway.
So... there IS a workaround, even if it is not that tidy.

Best regards
Carl

Thanks for your response.

There are a few things that will help and I think are a much, much better solution than sharing a build directory.

First, you should be able to specify multiple targets for MSBuild so that they are executed one after another. No need to setup separate builds for this.

In Bamboo 3.0, which is due out in a few weeks we have artifact passing. So if you do need or want to have separate builds, you can pass an artifact from one build to the other such that the build that receives the artifact can do further processing on it.

As mentioned previously you can also write a wrapper script if you need to, to invoke as many commands as you need.

We are also going to look at implementing BAM-1410 in a near future.

Due to this I think I will resolve this issue.

If your needs are not covered by what I outlined above, please leave a comment on this issue.

Cheers,
Anton

Hi!

In our case it is something like this:
We have a lot of components that are to be built in the same plan. They need to be built sequentially, because the latter projects depend on the outcome from the earlier ones. Between the different builds, we execute some scripts.
The builder we use is MSBuild.
The file transfer speed is unfortunately quite low too, and there are a lot of files to check out each time, so more than half the build time is spent retrieving files from source repository, etc.
We are currently using an older, discontinued build server, and are scouting a bit for a new one. Since we already use JIRA a bit, I thought I'd look a bit into Bamboo. And, apart from the problem with this issue, I like it a lot.

Regards
Carl