Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-6779

Successful build appears as failed (red) after deleting next "gray" build

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: maven-plugin
    • Labels:
      None
    • Environment:
      Windows 2008 server
    • Similar Issues:

      Description

      Scenario to reproduce:
      1. While you have successful builds in the list, stop the running build in the early stages, so it will appear as gray.
      2. Delete the last "gray" build

      The previous Successful build will appear as Failed (red), although in the build.xml appears
      <result>SUCCESS</result>
      Reloading configuration from the disk or restarting Hudson doesn't help.

        Attachments

        1. build.xml
          14 kB
        2. config.xml
          3 kB

          Activity

          Hide
          mindless Alan Harder added a comment -

          I wasn't able to reproduce this using a simple job with no SCM, just a shell script build step doing "sleep 20".
          Can you find more specific steps to see the problem?

          Show
          mindless Alan Harder added a comment - I wasn't able to reproduce this using a simple job with no SCM, just a shell script build step doing "sleep 20". Can you find more specific steps to see the problem?
          Hide
          liyatikal liyatikal added a comment -

          Actually it happens sometimes when deleting a failed build as well (not just a gray one).
          The most annoying thing is that I can't define when exactly it happened and when it doesn't.

          Please see the attached movie - I recorded the following flow:

          • I delete the failed build #3938
          • After #3938 is deleted, you can see that the previous one #3937 became red, although it appeared successful before. No need to say that its build.xml hasn't changed.
          Show
          liyatikal liyatikal added a comment - Actually it happens sometimes when deleting a failed build as well (not just a gray one). The most annoying thing is that I can't define when exactly it happened and when it doesn't. Please see the attached movie - I recorded the following flow: I delete the failed build #3938 After #3938 is deleted, you can see that the previous one #3937 became red, although it appeared successful before. No need to say that its build.xml hasn't changed.
          Hide
          mindless Alan Harder added a comment -

          does it appear red in both the build history widget and on its build page?
          please confirm that YOURHUDSON/job/JOBNAME/3937/buildStatus also redirects you to red.gif instead of blue.gif

          can you go to Manage Hudson / Script console and try this:

          hudson.model.Hudson.instance.getJob('JOBNAME').getBuildByNumber(3937).buildStatusUrl

          does this show "red" ?

          what do you get for:

          hudson.model.Hudson.instance.getJob('JOBNAME').getBuildByNumber(3937).result

          Show
          mindless Alan Harder added a comment - does it appear red in both the build history widget and on its build page? please confirm that YOURHUDSON/job/JOBNAME/3937/buildStatus also redirects you to red.gif instead of blue.gif can you go to Manage Hudson / Script console and try this: hudson.model.Hudson.instance.getJob('JOBNAME').getBuildByNumber(3937).buildStatusUrl does this show "red" ? what do you get for: hudson.model.Hudson.instance.getJob('JOBNAME').getBuildByNumber(3937).result
          Hide
          mindless Alan Harder added a comment -

          can you post config.xml for the job and build.xml for 3937?

          Show
          mindless Alan Harder added a comment - can you post config.xml for the job and build.xml for 3937?
          Hide
          liyatikal liyatikal added a comment -

          It seems like my attachment movie wasn't attached..
          To your questions:

          • it doesn't appear on the Builds History page - we have a lot of jobs and most of them maven jobs, so on this page i can see the "modules" builds. The build #3937 for this job is too old
          • http://myserver/hudson/job/ALL-CI/3937/BuildStatus point to the red.gif
          • running the command in the Console, I get the same result:
            Result: red.gif
          • running the second command, I get:
            Result: FAILURE
          • i am attaching config.xml for the job and build.xml for build #3937
          Show
          liyatikal liyatikal added a comment - It seems like my attachment movie wasn't attached.. To your questions: it doesn't appear on the Builds History page - we have a lot of jobs and most of them maven jobs, so on this page i can see the "modules" builds. The build #3937 for this job is too old http://myserver/hudson/job/ALL-CI/3937/BuildStatus point to the red.gif running the command in the Console, I get the same result: Result: red.gif running the second command, I get: Result: FAILURE i am attaching config.xml for the job and build.xml for build #3937
          Hide
          mindless Alan Harder added a comment -

          hm.. as you said, build.xml is unchanged (showing SUCCESS), so presumably a Hudson restart would put things right again. so something must happen in the delete action to change the in-memory result of that build.

          Show
          mindless Alan Harder added a comment - hm.. as you said, build.xml is unchanged (showing SUCCESS), so presumably a Hudson restart would put things right again. so something must happen in the delete action to change the in-memory result of that build.
          Hide
          mindless Alan Harder added a comment -

          ok, I played with a maven type job and was able to see this occur. On my 3rd delete, the status of the previous successful build changed to failure.

          Show
          mindless Alan Harder added a comment - ok, I played with a maven type job and was able to see this occur. On my 3rd delete, the status of the previous successful build changed to failure.
          Hide
          liyatikal liyatikal added a comment -

          As I mentioned before, restart doesn't change it.

          Show
          liyatikal liyatikal added a comment - As I mentioned before, restart doesn't change it.
          Hide
          mindless Alan Harder added a comment -

          Looks like this can occur if the set of modules changes.
          ie, if build #1 had module A which succeeded, and build #2 had module B which failed. when you delete build #2, build #1 somehow now looks at both module A and B to determine its overall success, and since module B failed (even though in the build you just deleted!) it now shows failure as the result of build #1.
          i'm not too familiar with the maven parts of the code, but still digging around to see why this happens..

          Show
          mindless Alan Harder added a comment - Looks like this can occur if the set of modules changes. ie, if build #1 had module A which succeeded, and build #2 had module B which failed. when you delete build #2, build #1 somehow now looks at both module A and B to determine its overall success, and since module B failed (even though in the build you just deleted!) it now shows failure as the result of build #1. i'm not too familiar with the maven parts of the code, but still digging around to see why this happens..
          Hide
          mindless Alan Harder added a comment -

          right.. since the result is coming from a module result (not the recorded moduleset result), that's why restart doesn't help.

          Show
          mindless Alan Harder added a comment - right.. since the result is coming from a module result (not the recorded moduleset result), that's why restart doesn't help.
          Hide
          mindless Alan Harder added a comment -

          thx to abayer, I now understand how Hudson is trying to group module builds under the parent build.. so you could build the whole project and get #123 and then run just module A, which makes #124 of module A but it still falls under project build #123.

          what happens here is the delete of the project build is only deleting that record and leaving its module builds around.. other code then interprets these as being individual module builds falling under that earlier parent project, and thus that earlier build now shows the failure status, if the orphaned module build was a failure.

          so I think if we fix up the deletion code here so delete of the project build also deletes the module builds, then this issue will be resolved. no orphans left to run off and find new parents

          Show
          mindless Alan Harder added a comment - thx to abayer, I now understand how Hudson is trying to group module builds under the parent build.. so you could build the whole project and get #123 and then run just module A, which makes #124 of module A but it still falls under project build #123. what happens here is the delete of the project build is only deleting that record and leaving its module builds around.. other code then interprets these as being individual module builds falling under that earlier parent project, and thus that earlier build now shows the failure status, if the orphaned module build was a failure. so I think if we fix up the deletion code here so delete of the project build also deletes the module builds, then this issue will be resolved. no orphans left to run off and find new parents
          Hide
          liyatikal liyatikal added a comment -

          That's great, cause it's another bug that gives me trouble!

          Show
          liyatikal liyatikal added a comment - That's great, cause it's another bug that gives me trouble!
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/maven-plugin/src/main/resources/hudson/maven/MavenModuleSetBuild/main.jelly
          trunk/hudson/main/maven-plugin/src/main/resources/hudson/maven/MavenModuleSetBuild/main.properties
          http://jenkins-ci.org/commit/32410
          Log:
          An aggregator style build doesn't necessarily have only 1 build per module,
          contrary to comment in this jelly.. you can trigger a build of an individual
          module from hudson UI. Refactor this jelly to use the current style most
          of the time, and the multi-build style whenever needed.
          This will help those affected by JENKINS-6779 as the orphaned builds will
          now be visible on the build page, so you can click on and then delete them.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/maven-plugin/src/main/resources/hudson/maven/MavenModuleSetBuild/main.jelly trunk/hudson/main/maven-plugin/src/main/resources/hudson/maven/MavenModuleSetBuild/main.properties http://jenkins-ci.org/commit/32410 Log: An aggregator style build doesn't necessarily have only 1 build per module, contrary to comment in this jelly.. you can trigger a build of an individual module from hudson UI. Refactor this jelly to use the current style most of the time, and the multi-build style whenever needed. This will help those affected by JENKINS-6779 as the orphaned builds will now be visible on the build page, so you can click on and then delete them.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
          trunk/hudson/main/test/src/test/java/hudson/maven/MavenProjectTest.java
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/32411
          Log:
          [FIXED JENKINS-6779] When a MavenModuleSetBuild is deleted, delete its contained
          module builds too.. this avoids orphaned module builds that then get looked at
          in determining the overall result for the prior ModuleSetBuild.. possibly
          mysteriously changing the displayed result for that prior build, with no visual
          indication as to why (this part just fixed in r32410.. build page will now list
          all module builds, so you can see/delete the orphaned module build).

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java trunk/hudson/main/test/src/test/java/hudson/maven/MavenProjectTest.java trunk/www/changelog.html http://jenkins-ci.org/commit/32411 Log: [FIXED JENKINS-6779] When a MavenModuleSetBuild is deleted, delete its contained module builds too.. this avoids orphaned module builds that then get looked at in determining the overall result for the prior ModuleSetBuild.. possibly mysteriously changing the displayed result for that prior build, with no visual indication as to why (this part just fixed in r32410.. build page will now list all module builds, so you can see/delete the orphaned module build).

            People

            Assignee:
            mindless Alan Harder
            Reporter:
            liyatikal liyatikal
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: