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

Adding a second project to the list to trigger causes NPE

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • core
    • None
    • RHEL 6.5 X86_64 Jenkins installed from RPM and updated via yum to 1.563

      Adding a second project to the projects to build in 'Post build Actions'
      results in only the first project being triggered and this message concerning an NPE at the end of the parent log.

      BUILD SUCCESSFUL
      Total time: 7 minutes 40 seconds
      Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
      Triggering a new build of prowess_intel #651
      FATAL: null
      java.lang.NullPointerException
      at hudson.model.Result.isBetterOrEqualTo(Result.java:125)
      at jenkins.triggers.ReverseBuildTrigger.shouldTrigger(ReverseBuildTrigger.java:133)
      at jenkins.triggers.ReverseBuildTrigger.access$000(ReverseBuildTrigger.java:83)
      at jenkins.triggers.ReverseBuildTrigger$1.shouldTriggerBuild(ReverseBuildTrigger.java:140)
      at hudson.tasks.BuildTrigger.execute(BuildTrigger.java:243)
      at hudson.model.AbstractBuild$AbstractBuildExecution.cleanUp(AbstractBuild.java:674)
      at hudson.model.Build$BuildExecution.cleanUp(Build.java:193)
      at hudson.model.Run.execute(Run.java:1752)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:231)

          [JENKINS-23083] Adding a second project to the list to trigger causes NPE

          Andrew Herron added a comment -

          OK, it wasn't that difficult after all.

          We only recently upgraded from a build older than 1.560, so we are only just starting to use Jenkins with the build trigger change in JENKINS-16956.

          The project causing the NPE had a bunch of projects in it's "build after other projects are built" trigger. This happened because we are still habitually using the previous behaviour where that list mirrored the post-build action "build other projects".

          I re-saved the project causing the NPE, and all projects in the "build after other projects" trigger, but the NPE persisted. Only once I deleted the "other projects" trigger did things return to normal.

          As far as I'm seeing, the reverse trigger is now broken and only the post-build action can be used. We're using 1.570.

          Andrew Herron added a comment - OK, it wasn't that difficult after all. We only recently upgraded from a build older than 1.560, so we are only just starting to use Jenkins with the build trigger change in JENKINS-16956 . The project causing the NPE had a bunch of projects in it's "build after other projects are built" trigger. This happened because we are still habitually using the previous behaviour where that list mirrored the post-build action "build other projects". I re-saved the project causing the NPE, and all projects in the "build after other projects" trigger, but the NPE persisted. Only once I deleted the "other projects" trigger did things return to normal. As far as I'm seeing, the reverse trigger is now broken and only the post-build action can be used. We're using 1.570.

          Daniel Beck added a comment -

          Andrew: JENKINS-23191 should be fixed in 1.570, but you're saying the reverse ("build after other") build trigger is still broken in that version?

          Daniel Beck added a comment - Andrew: JENKINS-23191 should be fixed in 1.570, but you're saying the reverse ("build after other") build trigger is still broken in that version?

          Andrew Herron added a comment -

          Yes. Using the same context as JENKINS-23191 for clarity:

          The reverse build trigger now saves correctly, but when Job A finishes, and attempts to trigger Job B, it gets the NPE described in this case (and, I believe, 23191).

          We just added a new Job B type to our system, and had to go around to all of the Job A types it depends on and update the post-build trigger to include Job B.

          Andrew Herron added a comment - Yes. Using the same context as JENKINS-23191 for clarity: The reverse build trigger now saves correctly, but when Job A finishes, and attempts to trigger Job B, it gets the NPE described in this case (and, I believe, 23191). We just added a new Job B type to our system, and had to go around to all of the Job A types it depends on and update the post-build trigger to include Job B.

          Jesse Glick added a comment -

          This really sounds like a duplicate of JENKINS-23191. Can you reproduce this from scratch in a new Jenkins installation containing that fix? Or is it just a matter of your having saved invalid configuration in the past due to JENKINS-23191 and have not since corrected the job configuration in all cases?

          Jesse Glick added a comment - This really sounds like a duplicate of JENKINS-23191 . Can you reproduce this from scratch in a new Jenkins installation containing that fix? Or is it just a matter of your having saved invalid configuration in the past due to JENKINS-23191 and have not since corrected the job configuration in all cases?

          Andrew Herron added a comment -

          Or, as the description of this case says, it could be having more than one project in the list.

          I think I have a test Jenkins server floating around somewhere, I'll see what I can do. I'm under a bit of a tight deadline at the moment though.

          Andrew Herron added a comment - Or, as the description of this case says, it could be having more than one project in the list. I think I have a test Jenkins server floating around somewhere, I'll see what I can do. I'm under a bit of a tight deadline at the moment though.

          Daniel Beck added a comment -

          Cannot reproduce on 1.570 with 3 freestyle projects ("up", "up2", "down") created from scratch:

          • configure "down" to be triggered after "up, up2" are finished
          • build "up2"

          build log of up2:

          Started by user Daniel Beck
          [EnvInject] - Loading node environment variables.
          Building on master in workspace /var/lib/jenkins/workspace/JENKINS-23083-up2
          Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
          Triggering a new build of JENKINS-23083-down
          Finished: SUCCESS

          build log of down:

          Started by upstream project "JENKINS-23083-up2" build number 1
          originally caused by:
           Started by user Daniel Beck
          [EnvInject] - Loading node environment variables.
          Building on master in workspace /var/lib/jenkins/workspace/JENKINS-23083-down
          Finished: SUCCESS

          Daniel Beck added a comment - Cannot reproduce on 1.570 with 3 freestyle projects ("up", "up2", "down") created from scratch: configure "down" to be triggered after "up, up2" are finished build "up2" build log of up2: Started by user Daniel Beck [EnvInject] - Loading node environment variables. Building on master in workspace / var /lib/jenkins/workspace/JENKINS-23083-up2 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered Triggering a new build of JENKINS-23083-down Finished: SUCCESS build log of down: Started by upstream project "JENKINS-23083-up2" build number 1 originally caused by: Started by user Daniel Beck [EnvInject] - Loading node environment variables. Building on master in workspace / var /lib/jenkins/workspace/JENKINS-23083-down Finished: SUCCESS

          Andrew Herron added a comment -

          Thanks for that

          My understanding of JENKINS-23191 is that it required 'down' to have a post-build action as well as a 'build after' trigger. Maybe that is required here as well? It's certainly the case in my setup.

          Andrew Herron added a comment - Thanks for that My understanding of JENKINS-23191 is that it required 'down' to have a post-build action as well as a 'build after' trigger. Maybe that is required here as well? It's certainly the case in my setup.

          Daniel Beck added a comment -

          Andrew: Still nothing. "up2" triggers "down" triggers "downer", all successful.

          Make sure that in your "down" (or rather "center") job config, one of the radio buttons of the "build after other" trigger is selected. That could be a leftover from the original bug.

          Daniel Beck added a comment - Andrew: Still nothing. "up2" triggers "down" triggers "downer", all successful. Make sure that in your "down" (or rather "center") job config, one of the radio buttons of the "build after other" trigger is selected. That could be a leftover from the original bug.

          Andrew Herron added a comment -

          Sadly, doesn't help. I might as well start talking real codenames to make it easier for me

          The new project I added yesterday is called limbo. It has about 5 projects that it depends on, and one that it triggers. We manually added limbo to the post-build action of each parent project after the bug yesterday.

          I had removed the "build after" trigger completely from limbo. I'm not sure if the radio button was selected or not. I just re-added it, confirmed the top radio button was selected and then triggered one of the parents in the list - a build called sugar. Sugar is one of our central projects, it has over 20 projects that depend on it (and are therefore listed in the post-build action).

          From sugar's build log:

          09:32:30 Archiving artifacts
          09:32:30 Recording test results
          09:32:39 Notified Stash for commit with id 329f2e748617ed52a00cf8be1512417714747f9d
          09:32:39 Recording fingerprints
          09:32:40 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
          09:32:40 Triggering a new build of polish
          09:32:40 Triggering a new build of gel
          09:32:40 sugar-tunic is disabled. Triggering skipped
          09:32:40 Triggering a new build of tral
          09:32:40 Triggering a new build of blab
          09:32:40 Triggering a new build of cereal
          09:32:40 Triggering a new build of snooker
          09:32:40 Triggering a new build of dragster
          09:32:40 FATAL: null
          09:32:40 java.lang.NullPointerException
          09:32:40 	at hudson.model.Result.isBetterOrEqualTo(Result.java:125)
          09:32:40 	at jenkins.triggers.ReverseBuildTrigger.shouldTrigger(ReverseBuildTrigger.java:133)
          09:32:40 	at jenkins.triggers.ReverseBuildTrigger.access$000(ReverseBuildTrigger.java:83)
          09:32:40 	at jenkins.triggers.ReverseBuildTrigger$1.shouldTriggerBuild(ReverseBuildTrigger.java:140)
          09:32:40 	at hudson.tasks.BuildTrigger.execute(BuildTrigger.java:243)
          09:32:40 	at hudson.model.AbstractBuild$AbstractBuildExecution.cleanUp(AbstractBuild.java:701)
          09:32:40 	at hudson.model.Build$BuildExecution.cleanUp(Build.java:194)
          09:32:40 	at hudson.model.Run.execute(Run.java:1778)
          09:32:40 	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          09:32:40 	at hudson.model.ResourceController.execute(ResourceController.java:88)
          09:32:40 	at hudson.model.Executor.run(Executor.java:234)
          

          Andrew Herron added a comment - Sadly, doesn't help. I might as well start talking real codenames to make it easier for me The new project I added yesterday is called limbo. It has about 5 projects that it depends on, and one that it triggers. We manually added limbo to the post-build action of each parent project after the bug yesterday. I had removed the "build after" trigger completely from limbo. I'm not sure if the radio button was selected or not. I just re-added it, confirmed the top radio button was selected and then triggered one of the parents in the list - a build called sugar. Sugar is one of our central projects, it has over 20 projects that depend on it (and are therefore listed in the post-build action). From sugar's build log: 09:32:30 Archiving artifacts 09:32:30 Recording test results 09:32:39 Notified Stash for commit with id 329f2e748617ed52a00cf8be1512417714747f9d 09:32:39 Recording fingerprints 09:32:40 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered 09:32:40 Triggering a new build of polish 09:32:40 Triggering a new build of gel 09:32:40 sugar-tunic is disabled. Triggering skipped 09:32:40 Triggering a new build of tral 09:32:40 Triggering a new build of blab 09:32:40 Triggering a new build of cereal 09:32:40 Triggering a new build of snooker 09:32:40 Triggering a new build of dragster 09:32:40 FATAL: null 09:32:40 java.lang.NullPointerException 09:32:40 at hudson.model.Result.isBetterOrEqualTo(Result.java:125) 09:32:40 at jenkins.triggers.ReverseBuildTrigger.shouldTrigger(ReverseBuildTrigger.java:133) 09:32:40 at jenkins.triggers.ReverseBuildTrigger.access$000(ReverseBuildTrigger.java:83) 09:32:40 at jenkins.triggers.ReverseBuildTrigger$1.shouldTriggerBuild(ReverseBuildTrigger.java:140) 09:32:40 at hudson.tasks.BuildTrigger.execute(BuildTrigger.java:243) 09:32:40 at hudson.model.AbstractBuild$AbstractBuildExecution.cleanUp(AbstractBuild.java:701) 09:32:40 at hudson.model.Build$BuildExecution.cleanUp(Build.java:194) 09:32:40 at hudson.model.Run.execute(Run.java:1778) 09:32:40 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 09:32:40 at hudson.model.ResourceController.execute(ResourceController.java:88) 09:32:40 at hudson.model.Executor.run(Executor.java:234)

          Andrew Herron added a comment -

          My apologies, it wasn't the project we created yesterday. We'd been running the buggy build of Jenkins long enough that two of the other projects which depend on Sugar had their "build after" trigger updated recently.

          Saving those fixed the issue.

          There are two things that make this a nightmare to track down:

          • When the NPE occurs, there is no indication in the log of which project caused it
          • The build that experiences the NPE is marked as successful so we never see a notification that there is an issue

          If we had that, this issue would be much easier to recover from.

          Andrew Herron added a comment - My apologies, it wasn't the project we created yesterday. We'd been running the buggy build of Jenkins long enough that two of the other projects which depend on Sugar had their "build after" trigger updated recently. Saving those fixed the issue. There are two things that make this a nightmare to track down: When the NPE occurs, there is no indication in the log of which project caused it The build that experiences the NPE is marked as successful so we never see a notification that there is an issue If we had that, this issue would be much easier to recover from.

            Unassigned Unassigned
            chris_jones Chris Jones
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: