I have defined a shared GitHub repository in Bamboo and enabled submodule support in the repository definition but Bamboo is ignoring the submodules that are present in this repository. It's not at all clear to me why this is happening and enabling verbose Git logging does not turn up any clues.
In addition, the help text for the "enable submodule support" checkbox is confusing at best - I'm not actually sure what it's trying to indicate, other than that submodule support might be disabled under certain conditions.
Other particulars:
- running Bamboo v4
- three build agents are defined and running locally on the Bamboo server
- running Git v1.7.5.4
Any help or insight would be greatly appreciated!
This issue appears to be resolved after deleting and re-creating the affected build plan along with an upgrade to Bamboo v4.1.
Here's what's showing up in the most recent log with verbose Git logging enabled for this plan's repository (slightly edited):
Updating source code to revision: 1234deadbeef /usr/bin/git version Fetching branch 'refs/heads/master' from 'https://github.com/Wyley/web.git'. /usr/bin/git fetch https://<url elided> +refs/heads/master:refs/heads/master --update-head-ok --progress --verbose From https:<url elided> = [up to date] master -> master Checking out revision 1234deadbeef. Creating local git repository in '/opt/bamboo-work/build-work/<job_dir>/.git'. /usr/bin/git log -1 --format=%d --decorate=full 1234deadbeef /usr/bin/git checkout -f master Already on 'master' Updated source code to revision: 1234deadbeef
If I manually execute the same commands in the same directory, I get exactly the same result that Bamboo does - ie. the submodule is not present.
Regarding expected behavior, after selecting the "enable submodule support" option in the shared repository definition (it's hosted on GitHub, if that makes a difference), I am expecting to see the repository's submodule initialized and up to date. What I actually see is just the empty directory where the submodule would be - that's what I meant by "Bamboo is ignoring the submodules".
Unfortunately, I don't have a verbose Git log from the very first run of this plan, so I'm not sure what Git commands were executed the first time this plan was run but it seems like 'git submodule init' and 'git submodule update' were not executed after the initial clone. The fetch command executed here is also missing the --recurse-submodules option.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you go to the Job's build log, what does the "checkout task" do according to the logs? If you perform the same steps in the same working directories, but manually using command line git - will that succeed in picking up submodules?
BTW: what does it mean "Bamboo is ignoring the submodules"? What do you expect from the Bamboo, and what is observed behavior? I'm not 100% sure I do understand the problem correctly...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Are these remote or local agents?
You need to make sure native git capability is defined on Bamboo Server in Administration/Server Capabiliities (and on agents, if you're using remote agents).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As I mentioned, the agents are local agents; the server also has a native Git capability defined. I tried adding a requirement to this particular job that requires Git but it didn't seem to make a difference.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ahh. I wasn't aware of that - sorry if that appeared snarky. :) I don't have any remote agents defined.
Command-line checkout works just fine, along with the 'submodule init' and 'submodule update' commands.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As I mentioned, the agents are local agents
You said "running locally" - you can run remote agents locally too. I assume the commandline checkout works fine?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.