Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
None
-
Centos 5, Hudson 1.369, Git Plugin 1.0
Description
These are the types of errors I get from it trying to fetch the submodules:
Fetching upstream changes from git@github.com:absperf/repo.git/subrepo/.git
[subrepo] $ /usr/bin/git fetch -t git@github.com:absperf/repo.git/subrepo/.git +refs/heads/:refs/remotes/origin/
ERROR: Repository not found. Make sure you include the .git, e.g. git@github.com:defunkt/ambition.git
fatal: The remote end hung up unexpectedly
ERROR: Problem fetching from origin - could be unavailable. Continuing anyway
ERROR: Could not fetch from any repository
FATAL: Could not fetch from any repository
hudson.plugins.git.GitException: Could not fetch from any repository
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:675)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:642)
at hudson.FilePath.act(FilePath.java:753)
at hudson.FilePath.act(FilePath.java:735)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:642)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1038)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
at hudson.model.Run.run(Run.java:1258)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:129)
Prior to the 1.0 release of the git plugin I still got these errors, but the build continued despite them and I could handle updating the submodules myself. Now the plugin is useless since most of my projects have submodules.
Attachments
Activity
mclaughlin77
created issue -
Ok, I've figured some of this out - there are like three different ways of handling submodules in the git plugin, for no obvious reason. The errors you're seeing are showing up when it tries to guess the submodule URL, and, well, it guesses very, very badly, and I'm not sure why it's even trying. I'd put logic in the method that's called from to fail if no repositories can be fetched - but that shouldn't actually apply to this weird submodule logic, so I'm changing that. Then after getting past that, it tries "git submodule init", "git submodule sync", and "git submodule update" - which is good, I think. Though it tries another round of the stupid fetches too. And then there's a third approach that's implemented but not exposed - I have no idea what's going on there.
So, for now, I'm getting rid of the behavior that treated failure to fetch from an auto-guessed submodule repository as a complete failure. I'm considering just nuking the auto-guess/fetch stuff entirely, but I'm not sure if someone might already have builds depending on that. Sigh. Anyway, you can find a new HPI file at http://ci.hudson-labs.org/job/plugins_hudson-git-plugin/lastSuccessfulBuild/org.jvnet.hudson.plugins$git/artifact/org.jvnet.hudson.plugins/git/1.1-SNAPSHOT/git.hpi shortly. Lemme know how it works.
Integrated in 
plugins_hudson-git-plugin #13
JENKINS-7141 Submodule fetches are not working under any conditions, so far as I can tell, so they should not be contributing to the overall fetch success
Andrew Bayer :
Files :
- src/main/java/hudson/plugins/git/GitSCM.java
| Field | Original Value | New Value |
|---|---|---|
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
mclaughlin77
added a comment - That got me back in business. Thanks for the quick resolution. | Status | Resolved [ 5 ] | Closed [ 6 ] |
| Workflow | JNJira [ 137238 ] | JNJira + In-Review [ 204435 ] |
I'll confess to being fairly confused about submodules in the first place. I guess what you're saying is that submodules weren't actually working in the first place, but now it's taking the whole build down? Is it able to fetch your main repo first?