-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
Ubuntu 12.04.1, Jenkins 1.621-1.624
Build completes satisfactorily, but NPE while triggering dependent builds. I upgraded to 1.623 to see if that resolved the fault, but the results are identical. The log shows only 4 of 10 builds triggered, but it may not have been flushed at the point of the fault. All builds are freestyle using multiple shell steps, with no Java or Groovy components or steps. This problem is 100% repeatable with certain builds.
Tail of an example failing build:
17:44:08 Archiving artifacts
17:44:11 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
17:44:11 Triggering a new build of trap
17:44:11 Triggering a new build of snort-e
17:44:11 Triggering a new build of tcparchive_982
17:44:11 Triggering a new build of deepinspect
17:44:11 FATAL: null
17:44:11 java.lang.NullPointerException
17:44:11 at jenkins.triggers.ReverseBuildTrigger.shouldTrigger(ReverseBuildTrigger.java:111)
17:44:11 at jenkins.triggers.ReverseBuildTrigger.access$000(ReverseBuildTrigger.java:84)
17:44:11 at jenkins.triggers.ReverseBuildTrigger$1.shouldTriggerBuild(ReverseBuildTrigger.java:141)
17:44:11 at hudson.tasks.BuildTrigger.execute(BuildTrigger.java:245)
17:44:11 at hudson.model.AbstractBuild$AbstractBuildExecution.cleanUp(AbstractBuild.java:687)
17:44:11 at hudson.model.Build$BuildExecution.cleanUp(Build.java:200)
17:44:11 at hudson.model.Run.execute(Run.java:1788)
17:44:11 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
17:44:11 at hudson.model.ResourceController.execute(ResourceController.java:98)
17:44:11 at hudson.model.Executor.run(Executor.java:381)
17:44:11 Finished: SUCCESS
- duplicates
-
-
- Resolved
-
[JENKINS-29807] NullPointerException when triggering dependent builds
sseidel
added a comment - Problem seemed to be a disabled project which still had the failing project as upstream dependency. After deleting the disabled project all downstream triggers executed without NPE on 1.624.
sseidel
added a comment - Problem seemed to be a disabled project which still had the failing project as upstream dependency. After deleting the disabled project all downstream triggers executed without NPE on 1.624. 
John Mellor
added a comment - This issue is not fixed by moving up to 1.625 release.
It appears to be caused only whenever the list of dependent builds includes a disabled build.
John Mellor
added a comment - This issue is not fixed by moving up to 1.625 release.
It appears to be caused only whenever the list of dependent builds includes a disabled build. Confirmed with 1.625, if a job is set up using the Build Trigger option "Build after other projects are build" and it is disabled the null exception will be triggered when the upstream build job tries to trigger it's downstream build jobs.
Régis Desgroppes
added a comment - Still happening w/ 1.627. Rolling back to 1.620. 
Sverre Moe
added a comment - - edited rdesgroppes Would rolling back to 1.620 work (solve the problem)? John Mellor
added a comment - The critical problem here is that all of the dependent builds after a disabled dependency in the list are not triggered, thus breaking the entire build tree. This means that in real use, the entire toolchain needs to externally work around Jenkins instead of relying on it. This affect a LOT of users. Can we please get this fixed in the 1.628 release?
John Mellor
added a comment - The critical problem here is that all of the dependent builds after a disabled dependency in the list are not triggered, thus breaking the entire build tree. This means that in real use, the entire toolchain needs to externally work around Jenkins instead of relying on it. This affect a LOT of users. Can we please get this fixed in the 1.628 release? Régis Desgroppes
added a comment - djviking it doesn't solve the problem per se (we'd like to switch to a more recent Jenkins version) but, at least, it brings back our master into an acceptable state.
Régis Desgroppes
added a comment - djviking it doesn't solve the problem per se (we'd like to switch to a more recent Jenkins version) but, at least, it brings back our master into an acceptable state. 
Peter Novotnak
added a comment - Any idea on complexity to fix / timeline if someone is already taking a look at this?
Peter Novotnak
added a comment - Any idea on complexity to fix / timeline if someone is already taking a look at this? I'm seeing this same symptom/trace - however, I do NOT have a disabled build. Also tried with 1.627 with no luck, rolling back to 1.620 now to see if that works.
Sorry, actually, I DID have a disabled build... just missed it when reviewing the config. 1.620 definitely worked again for me as well.
It is semantics, but actually JENKINS-29876 is the duplicate, since this issue was reported 5 days before.
Sverre Moe
added a comment - - edited It is semantics, but actually JENKINS-29876 is the duplicate, since this issue was reported 5 days before. True. I decided to resolve this way because that other issue has a similar number of watchers/votes, but the attention of Kostya.
Having the same problem. This is a major problem for us because the whole CI chain fails - downstream projects are not triggered hence tests are not run and automated deployment does not happen.
Last version which works is 1.620.