How to prevent git checkout on server when using remote agents
Asked by Hugo Amiard:

I'm trying to find an answer to an issue which seemingly does not have a solution explained anywhere yet.  
We use remote agents to do all of our bamboo builds, and we do \*not\* use the default agent on the bamboo server.  
The bamboo server itself does not build: its agent is already disabled in the agent list  

However, it seems that bamboo still makes the server check out its own copy of the git repositories that the remote agents are using, for some obscure and unexplained reason. This causes the server to run out of disk space, since it's never supposed to checkout those repositories in the first place  

The only reference to this problem I could find anywhere on the internet is here:  
<https://serverfault.com/questions/304320/how-do-i-get-bamboos-disk-usage-under-control>  

However, no one gave a satisfactory answer, actually no one answered the question at all. This is not about disabling the default agent, since in both cases (ours, and the person that asked this question) the default agent is already disabled  
This is not about clearing the build directory before or after the job, since we are talking about two different machines here: the unwanted checkout here is happening on the server, not on the remote agent  

If anyone knows anything that could help solve this issue, we would be infinitely grateful  

Update: I just found in the "Repository Settings" of the administration panel, that we have some understanding or control on those server-side cache  

However, that page says "Git caches can be configured to reside both on the server and remote agents". Well it appears that that page is lying, as I have found nowhere how those caches can be configured to reside on the server and remote agents. Actually, I haven't found a place to configure those caches at all, and the documentation isn't helping :/


Answers:
author: Alexey Chystoprudov
body: Bamboo Server keeps repository caches to use them at change detection actions. Every build result has list of commits and files changed at this build. This list is prepared by server before job is sent to agent.

comments: author: Hugo Amiard
body: Thanks a lot for the information. I have a few follow-up questions then:  
- If repository cache is tied to change detection, would it be possible to disable both somehow ? I don't see getting a list of changed files as an integral part of bamboo core functionality, it seems like a rarely used functionality (even googling for that, I only find an obscure reference to an entry point in bamboo REST API)  
- I'm not sure why change detection means the server has to \*checkout\* the files. It seems that git has all the functionality needed to get that information without ever checking out any files (\`git show origin/\<commit\>\` and \`git diff origin/\<c1\>..origin/\<c2\>\` seem to give all the information that bamboo could ever rely on). I understand this is probably an implementation detail, but a very stinging one in this case. The worse part is that it also checks out the git LFS files, which is really an infrastructural nightmare in case of big repositories. So I definitely see this as a significant improvement that could be planned for us customers of bamboo  
- It would be very nice if your answer was explained in the documentation. Apologies if I overlooked a piece of documentation somewhere, but so far I haven't found a piece of documentation that explains exactly what you just said


author: Alexey Chystoprudov
body: It's implementation details, originally Bamboo was supporting repositories like SVN, Perforce, CVS which doesn't support commands Git supports now. Still to enrich build result with files changed since previous build you need to keep these files and commit hashes somewhere.

Regarding LFS it's a way cache works now and I'm agree it's not that required for server if no local agents used.


author: Shayn Ecatern
body: While I'm not an expert in this specific issue, I'd recommend reaching out to the Bamboo community or their support. They are likely more familiar with the intricacies of Bamboo configurations and may have encountered similar scenarios before. It's possible that they could provide valuable insights or even offer workarounds or solutions.  
Additionally, you might want to explore [darkvr.io](https://darkvr.io/) for tech-related information and solutions. It's always beneficial to have multiple sources to refer to when troubleshooting technical issues. Good luck with resolving your Bamboo problem, and I hope you find a solution soon!