disabling repository caching

[V]

Is it possible to disable repository caching in bamboo (either globally or per plan)?

[Przemek Bruski]

Could you tell us something about your use case? Why would you like to do this?

[V]

Trying to push changes to a git-repository wont work if bamboo pushes the changes to the repository-cache.

[mark_gillespie]

This is causing is huge headaches.   Trying to tag a repository during deployment.

We have used the official tag plugin, but this fails if the tag exists, so it's no use for us (we need to delete the tag and re-tag).  Tried writing our our script, this fails also, as it's tagging the local cache.   Can't disable caching, as our deployment runs on a local agent.   Can't tag via ssh, as we can't provide a password in the URI.

So what can we do?  Anyone any ideas?

[Ryan Daniels]

I would find a product other than Bamboo. People have been complaining about this for years. It is an obvious bad design decision, at least not to give the option to disable it, but yet Atlassian has not added the ability to disable it.

One thing I can tell you that you are doing wrong is by not using keys for ssh instead of relying on passwords.

Next, you have to add a git remote to point back to your original repo URL which is provided in an environment variable by Bamboo. Then when you push, push to that remote instead of origin.

Another option is to use the new git push task type provided by Bamboo if your version is new enough to have it.

[Jason Fitch]

agree that this "feature" is wholly unnecessary, and the inability to turn it off is yet another case of Atlassian ignoring Bamboo feature requests for years on end.  Bamboo may not be dead, but it's clearly on life support.

the cache caused us all sorts of headaches re: tags added outside the cache.  e.g., deleting a tag from the git repo, only to have it added back when another tag was added to the cache.  deleting the cache was the only way out of the problem.  would unquestionably turn off the cache if possible.

@mark_gillespie , definitely set up the SSH key as @Ryan Daniels pointed out.  we do this at the end of our build step to tag and get the tag out of the cache:

git tag -a 'vX.Y.Z' -m 'some comment';
git push --tags '${bamboo.repository.git.repositoryUrl}' '${bamboo.repository.git.branch}';

bamboo.repository.git.repositoryUrl will be the ssh url to your git host.

[mark_gillespie]

"bamboo.repository.git.repositoryUrl will be the ssh url to your git host."

not for our use-case.  This is our deployment project, and we check out a deployment "stub" from a linked repository at the start of our deployment.  None of the build variables have any reference to this deployment stub.  Already wasted way too much time on this.  The only reason I am doing this, is because the new tagging plugin doesn't have a force option.  if it did, I wouldn't have to try and hand script this, and come up against the repository cache problems (as the tagging plugin deals with caching and accounts/permissions).

I raised this feature request.

https://jira.atlassian.com/browse/BAM-20331

But given the glacial speed of Atlassian feature requests, I'm not going to hold my breath.

[Anton Danielsson]

We are not able to use the "Repository Tag" task either because it only creates lightweight tags in git. Releases typically use annotated tags.

And just doing `git push` goes to the cache... It would make more sense if the push url was kept to point at the original remote. Dosen't really make sense to push to the cache... It's of course possible to work around it but it's a bit of a pain.

[Pawel Skierczynski]

There is advanced option "Enable Repository Caching on Remote Agents" on repository configuration.

But what you may try instead is setting origin in additional task after checkout and before push to your git server.

git remote set-url origin <url>

Until next change detection fires cache will be invalid though.

[V]

I already disabled it on remote agents but that wont solve the problem when the plan is run on the main-server. Also setting the remote for git is not possible for me, because I can't (wont) hardcode the URL and using the environment-variable bamboo provides is not working because I have no easy way of adding username:password@ to it. If it was possible to disable repository caching altogether it would be so much easier for me ...

[Shannon Carey]

This is also discussed in the Bamboo KB. https://confluence.atlassian.com/display/BAMKB/Merging+and+pushing+to+remote+repository+failsand the issue tracker https://jira.atlassian.com/browse/BAM-11930I have the same problem.

[Gary Kennedy]

Voting for this issue. I've made a couple of scripts to do fetch/push for me and I just pass them the repository url and the branch(es) to fetch/push. The url is not hardcoded as I use the bamboo variables to give me that. (eg, bamboo.planRepository.repositoryUrl - see https://confluence.atlassian.com/display/BAMBOO/Bamboo+variables) The plan branch name is also passed via bamboo variable, but other branch names do need to be hardcoded. (Luckily it's just develop + master) HOWEVER - The repository cache keeps old branches around which is screwing with jgitflow which now only lets you have one release branch at a time, which means I have to delete the repository cache EVERY time I run the release plan. Seriously screwed up.

[Ryan Daniels]

The repository cache is a horrible feature. It causes so many problems. Not only do your tags not make it to the remote agents unless you check the remote caching option, but you have to come up with crazy workarounds to the fact that you can't simply release using Bamboo. At this time, I suggest that people do NOT buy Bamboo because of the repository caching. None of these things should be an issue in the first place. The repository caching is horrible and there is no way to disable it.