Git repository management in plans

Christian Nentwich

Hi there,

we are currently evaluating Bamboo because we are looking to switch from another product. We're generally happy - our Maven and C++ builds both work, thumbs up!

One thing we need to understand is how Git repositories are shared across plans. It seems every plan defines its own Git repo?

The way we have currently git it set up, we have a project and several plans like this:

Project

- Plan1

- Plan2

- Plan3

- ...

All these plans build a Maven project, and all these Maven projects are in the same Git repository. We're having to add a git repo URL to each plan, and it seems that bamboo clones the repo once per plan? This repository is currently 150MB and is forecast to grow to almost 1 Gigabyte, so we're not too keen on that.

Is there something we are overlooking or can do better? (Hint: "don't set up your projects this way" is not a good answer, they are already set up this way and we're not letting the tail wag the dog

The "competing product" manages repositories on a global shared basis, and lets individual plans reference it. Is there something similar?

Thanks!

Christian

Przemek Bruski

I don't know - it's not been an issue, because basically the plans I was referring to build different sub-projects in the repository. None of the builds would touch the same files.

What if you want to build the same project concurrently? For example, you have 6 commits, the build is triggered, but than another commit comes? Or, what happens if you commit to plan 1, the build is started and then you commit to plan 2 and 3? You can't (shouldn't) update a shared repository while another plan is built.

Both. Checkout time on this repo already isn't great.

Optimise for your most costly resource: developer's time. A shared checkout is a bottleneck - Bamboo is written in a way that let's you paralellize as much as possible - so that you can have many builds of the same/different plans running at the same time. In this way, we minimise the waiting time for a developer.

You probably can set up Bamboo in a way that will let you use a shared checkout (disable concurrency on plans, block plans from building when other plans are being built, symlink the build working directory). But honestly, that won't make sense for people idly waiting for builds to go green.

Checkout time and disk space requirements can be minimised by using shallow clones.

For local agents, checkout time is also minimised by using Bamboo's automatic caching mechanism (a shared repository used only for change detection and initial clone of the plan), so a remote clone will only be done once.

Another option for reducing the checkout time is not removing the build directory after the build is finished - instead of clone, Bamboo will only update the directory. You would have to do that in the shared reposository
approach anyway.