-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Ubunbu Karmic
If there is a problem fetching new changes from a remote repo, this doesn't fail the build. Example:
ERROR: Permission to simplegeo/python-geojson denied to geebus. fatal: The remote end hung up unexpectedly ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
Despite this, the build proceeds and is considered successful. This is extremely misleading, as it contains no new changes from the only repository it is configured to pull from. While I believe this behavior is nonsensical in the majority of cases, I think that one of two things should be changed:
1. If every remote repo fails to update, fail.
OR
2. Add an option to fail if any remote repo fails to update.
- is duplicated by
-
-
- Closed
-
- is related to
-
JENKINS-4960 Provide a SCMCheckoutStrategy to checkout only once for all matrix entries
-
- Open
-
[JENKINS-6902] Errors fetching from remote repos don't fail the build
Fixed in latest at github.com/hudson/Hudson-GIT-plugin's master branch - if all fetches fail, the build will be marked as failed.
jlongman
added a comment - Why would a build succeed if ANY of the source repositories fail? Is there any scenario where this makes sense? Have people said they would be happy if the build continued silently with out-of-date code?
(Who are these people? I want to make sure I never submit a job application to them... 
)
jlongman
added a comment - again
Why would a build succeed if ANY of the source repositories fail? Is there any scenario where this makes sense? Have people said they would be happy if the build continued silently with out-of-date code?
(Who are these people? I want to make sure I never submit a job application to them... ) I can see situations where you're pulling from multiple repos, and if one of those repos should happen to be inaccessible or go away, that shouldn't stop the build from proceeding. But I definitely agree that there's a problem if no repo can succeed. And given that most configurations are going to just have the one repo anyway...
eguess74
added a comment - Hudson 1.379, git plugin v 1.1, only one repository configured to fetch from. The repository got renamed on the remote side. Fetch has failed during the poll. But it still says "continuing anyway"
The problem is not fixed
eguess74
added a comment - Hudson 1.379, git plugin v 1.1, only one repository configured to fetch from. The repository got renamed on the remote side. Fetch has failed during the poll. But it still says "continuing anyway"
The problem is not fixed jlongman
added a comment - @abayer - I finally understand what you mean by your reply - seriously I had no idea why anyone would want what you suggested. Multiple repositories should be renamed to indicate redundant or backup repositories as it doesn't imply a collection of repositories, rather backups, which is what I (and the creator of CORE-8082) inferred. "Multiple" tends to imply a collection - all mandatory - rather than a redundancy in my mind. Also, what happens if a repo fails partway through (does it clean the workspace before moving onto the next repo?)
jlongman
added a comment - @abayer - I finally understand what you mean by your reply - seriously I had no idea why anyone would want what you suggested. Multiple repositories should be renamed to indicate redundant or backup repositories as it doesn't imply a collection of repositories, rather backups, which is what I (and the creator of CORE-8082) inferred. "Multiple" tends to imply a collection - all mandatory - rather than a redundancy in my mind. Also, what happens if a repo fails partway through (does it clean the workspace before moving onto the next repo?)
A common use case for the issue as described is for a build that has a sub-component that lives in another version control system.
Think of any large open source project, which depends on many smaller libraries;
For example, say you want to pull from super-duper-common-lib (e.g., zlib) via github, and without that one critical foreign lib the entire build will not work.
I like option #1 - I'm not a particular fan of this behavior either, but I don't want to break anyone depending on the build continuing if one of multiple repos fails, and I don't want to add more configuration options than absolutely necessary.