Error with git submodules ?
rostyboost opened this issue · comments
Hello,
I am trying to make Kochiku CI work for a git repository that contains a submodule.
For some reason, the BuildPartioningJob fails. Here is what the Resq error queue gives me:
non-0 exit code pid 13187 exit 1 returned from [git submodule --quiet update]
/app/kochiku/kochiku/releases/20130919182453/lib/git_repo.rb:76:in `run!'
/app/kochiku/kochiku/releases/20130919182453/lib/git_repo.rb:30:in `block (2 levels) in inside_copy'
/app/kochiku/kochiku/releases/20130919182453/lib/git_repo.rb:17:in `chdir'
/app/kochiku/kochiku/releases/20130919182453/lib/git_repo.rb:17:in `block in inside_copy'
/usr/local/rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/tmpdir.rb:88:in `mktmpdir'
/app/kochiku/kochiku/releases/20130919182453/lib/git_repo.rb:13:in `inside_copy'
/app/kochiku/kochiku/releases/20130919182453/app/jobs/build_partitioning_job.rb:17:in `perform'
/app/kochiku/kochiku/releases/20130919182453/app/jobs/job_base.rb:22:in `perform'
I can trigger a green build for my repository without the submodule.
Any idea on what could go wrong? Do I need any special configuration to make Kochiku work with submodules?
Thanks
This should just work. There is no extra configuration.
Are you 100% certain that the user has access to the repository of the submodule? You could test this by becoming the kochiku user on the server and attempting a git clone of the submodule.
Thanks for the quick answer @robolson .
Yes I did try what you suggested as a kochiku user, and it works fine.
I think I understand what's happening though: the issue is coming from the local cache of repositories that Kochiku creates.
It looks like the way it works is that it's only cloning the repo into the cache once, if the directory doesn't exist (see here). But if master doesn't happen to have submodules at all, and I push a new branch including a submodule, then the .gitmodules file won't ever be pulled (see here), and the redirect of submodules to the cached repo will make the command git submodule --quiet update fail.
I'm not a ruby expert, and the run! method prevents me to see the exact stack trace, so let me know if my interpretation is wrong.
Wiping out the cached repo and re-triggering a build worked.
Yep. Your explanation is correct—I see the bug now. If a submodule is added after the initial clone of the repo then it will not work because of the redirect of the remotes to the submodules in the cached repo.
I think the best solution may be to only "redirect" the submodules which are also present in the cache repo. This will result in some inefficiency as the "new" submodules will end up being cloned in entirety many times over but at least they will work.
I will work on making the fix I described.
Yes, it sounds like a reasonable fix. Thank you!
Thanks @robolson !