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

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

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • maven-plugin
    • None
    • Windows 2008 server

      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.

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

          [JENKINS-6779] Successful build appears as failed (red) after deleting next "gray" build

          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

          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

          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.

          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.

          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.

          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.

          liyatikal added a comment -

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

          liyatikal added a comment - As I mentioned before, restart doesn't change it.

          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..

          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..

          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.

          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.

          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

          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

          liyatikal added a comment -

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

          liyatikal added a comment - That's great, cause it's another bug that gives me trouble!

          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.

          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.

          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).

          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).

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

              Created:
              Updated:
              Resolved: