-
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
ieure
created issue -
ieure
made changes -
| Description |
Original:
If there is a problem fetching new changes from a remote repo, this doesn't fail the build. Example: {code} 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 {code} 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. |
New:
If there is a problem fetching new changes from a remote repo, this doesn't fail the build. Example: {code} 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 {code} 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. |
Fixed in latest at github.com/hudson/Hudson-GIT-plugin's master branch - if all fetches fail, the build will be marked as failed.
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Link |
New:
This issue is duplicated by |
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 eguess74
made changes -
| Resolution | Original: Fixed [ 1 ] | |
| Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
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.