if I run:
git branch -r | wc -l
in a local git sandbox that I created via a `git clone`, I will get approx 433 branches.
This is about (possibly exactly, but I didn't count them) what Bitbucket shows me if I go the branches page (and keep scrolling down).
So far so good, as I believe that is how many branches we currently have.
Now, if I go onto our Bamboo linux agent, and go into a directory that was created by one of my build plans, and run that same command, I get 1,862 branches.
Running, `git fetch --prune` seems to have no effect.
I've seen some articles that mention if the git sandbox was created with a `git fetch` (rather than a `git clone`) then `git fetch --prune` may not have any effect, but I need to have that command have an effect.
My Bamboo build plan gets the list of remote branches and operates on it, by creating a report full of information about "current" existing branches, along with some JIRA information.
Currently this report has 1429 plus branches that are not "current" and have since been deleted.
Thus my report has mostly wrong OBSOLETED information.
So the question is, what does Stash/Bitbucket do during the "checkout source code" step that prevents my running `git fetch --prune` effectively, and why would my newly created git sandbox on the Bamboo agent have old and outdated branch names?
I need some work-a-rounds to this issue.
yes, I have clicked both boxes for cleaning up the work space, but this has no effect and has nothing to do with the problem at hand.
If I don't clean up the workspace, thus allowing my to log into that Linux agent, and `cd` into the build directory,
issuing `git fetch --prune` does nothing and
`git branch -r | wc -l` still shows 1800+ branches.
via the Stash branch page which is about 20 pages of 25 branch names (around the 423 that I get from running `git branch -r | wc -l` on a pruned git sandbox on my laptop, or other co-worker's laptop), if i start typing any of the branch names that we know we don't have, the page turns empty. They aren't there. Nor are they there on a fresh checkout, using `git clone ...`.
So yeah, the command that Bamboo is using to get the source code, must not be `git clone` and there is something cached somewhere, such that when Bamboo does do the command to get the source code, it's getting it from this cached place, that has everything from the beginning of time.
(at least that's my interpretation of what's going on)
I have done that as a workaround, as thankfully, I spent oodles of time a couple months ago "mucking" to get that (ssh) authentication to work. I did that naively for a different problem that I didn't really have.
So yes, doing my own `git clone` in a bamboo build plan, works exactly as doing it on my own laptop.
But I would like a slicker solution that leverages Bamboo's Source Code Checkout.
Maybe if Atlassian added a checkbox in the "SourceCodeCheckout" task, that would do a real `git clone` and no shortcuts.
that's a good idea (didn't even know there was an advanced options section.)
Everything is unchecked except for "Use shallow clones".
Aside: The Linux client that I am having a problem with, is a "local" client. Not a remote client, so maybe that check box wouldn't even apply to this problem.
And having said that, I will have to test to see if I have the same problem of where `git --prune` has no effect, or if the git sandbox is already un-cached (and pre-pruned) on our "remote" Windows clients.
We’ve been building a plugin to integrate Bitbucket Server and Jenkins CI, and I’m excited to announce that our alpha is ready to download and install. It lets you seamlessly configure a Jenkins job ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events