Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Minor
-
Resolution: Fixed
-
Component/s: mercurial-plugin
-
Labels:None
-
Similar Issues:
Description
See pull request @ https://github.com/jenkinsci/mercurial-plugin/pull/31
Currently it appears that the Mercurial plugin doesn't check the exit code of the hg pull used to update the repository (see hudson.plugins.mercurial.MercurialSCM#update() - https://github.com/jenkinsci/mercurial-plugin/blob/master/src/main/java/hudson/plugins/mercurial/MercurialSCM.java#L496)
So, if the upstream repo has gone away for some reason (say, hypothetically, I've rm-ed it), the hg pull will fail and exit with a status code of 255, but the build will continue regardless
Attachments
Issue Links
- is duplicated by
-
-
- Resolved
-
Activity
Kristian Glass
created issue -
Rene Kroon
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | In Progress [ 3 ] |
Rene Kroon
made changes -
| Description |
Currently it appears that the Mercurial plugin doesn't check the exit code of the {{hg pull}} used to update the repository (see {{hudson.plugins.mercurial.MercurialSCM#update()}} - https://github.com/jenkinsci/mercurial-plugin/blob/master/src/main/java/hudson/plugins/mercurial/MercurialSCM.java#L496) So, if the upstream repo has gone away for some reason (say, hypothetically, I've rm-ed it), the {{hg pull}} will fail and exit with a status code of 255, but the build will continue regardless |
See pull request @ https://github.com/jenkinsci/mercurial-plugin/pull/31 Currently it appears that the Mercurial plugin doesn't check the exit code of the {{hg pull}} used to update the repository (see {{hudson.plugins.mercurial.MercurialSCM#update()}} - https://github.com/jenkinsci/mercurial-plugin/blob/master/src/main/java/hudson/plugins/mercurial/MercurialSCM.java#L496) So, if the upstream repo has gone away for some reason (say, hypothetically, I've rm-ed it), the {{hg pull}} will fail and exit with a status code of 255, but the build will continue regardless |
Rene Kroon
made changes -
| Assignee | Jesse Glick [ jglick ] | Rene Kroon [ sioux ] |
In the current state, this bug totally undermine the whole notion of CI and automatic testing. Because teams, which rely on Jenkins checking out and verifying the latest changes, will silently get some arbitrary older version verified. Which may lead to wrong decisions and wrong versions being deployed to the production. With potentially huge business impact.
Code changed in jenkins
User: Ben Rogers
Path:
src/main/java/hudson/plugins/mercurial/MercurialSCM.java
src/test/java/hudson/plugins/mercurial/SCMTestBase.java
http://jenkins-ci.org/commit/mercurial-plugin/0854a77f154cbadf71835731ea6f5f90593f42f8
Log:
[FIXED JENKINS-15806] - Fail build on failed pull
This is an update to pull request #31 and #40
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/hudson/plugins/mercurial/MercurialSCM.java
src/test/java/hudson/plugins/mercurial/SCMTestBase.java
http://jenkins-ci.org/commit/mercurial-plugin/0b005bd18419f81ecb2d98827054273d9d70fbdc
Log:
Merge pull request #56 from ben--/master
[FIXED JENKINS-15806] - Fail build on failed pull
Compare: https://github.com/jenkinsci/mercurial-plugin/compare/c064ebaab7fd...0b005bd18419
| Link |
This issue is duplicated by |
Since upgrading to 1.50, when my jobs get triggered for any reason other than a commit to the repository (e.g. an upstream trigger or a manual build) they get failed by the Mercurial plugin because the hg pull found no changes:
Started by user Andrew Johnson [EnvInject] - Loading node environment variables. Building on master in workspace /var/lib/jenkins/jobs/epics-pvaPy/workspace [workspace] $ hg showconfig paths.default [workspace] $ hg pull --rev default pulling from http://hg.code.sf.net/p/epics-pvdata/pvaPy no changes found ERROR: Failed to pull ERROR: Failed to pull [WARNINGS] Skipping publisher since build result is FAILURE Sending e-mails to: anj@aps.anl.gov Notifying upstream projects of job completion Finished: FAILURE
To get them to build in this state I have to wipe out the work-space so they get cloned again. This is a major problem which I'm pretty sure this change was responsible for, so I will be reverting to 1.49.
| Assignee | Rene Kroon [ sioux ] | Jesse Glick [ jglick ] |
| Resolution | Fixed [ 1 ] | |
| Status | Resolved [ 5 ] | Reopened [ 4 ] |
@anjohnson please file any follow-up issues separately and link to the original bug fix. Generally reopening an issue should be reserved for the case that the fix somehow missed correcting the original problem at all.
In this case the problem is likely that you have an older Mercurial installation which improperly reports a nonzero exit status when pull has nothing to pull. Upgrade it.
| Resolution | Fixed [ 1 ] | |
| Status | Reopened [ 4 ] | Resolved [ 5 ] |
| Workflow | JNJira [ 146607 ] | JNJira + In-Review [ 192001 ] |
Note that this also affects repositories that need to be recovered (using 'hg recover'). Currently Jenkins just builds the last change that was pulled before the repository got in a bad state. This way it is very hard to see that this is the issue. Checking the exit code and stopping would make it easy to replay by hand at the right point in the build.