-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Jenkins version 2.11
After updating from 2.10 to 2.11, I see the following stacktrace for a job that has SCM polling enabled:
Jun 27, 2016 2:56:39 PM hudson.triggers.SCMTrigger$Runner runPolling
SEVERE: Failed to record SCM polling for hudson.maven.MavenModuleSet@6ff62dfd[WFIAM Build]
java.lang.NullPointerException
at jenkins.triggers.SCMTriggerItem$SCMTriggerItems$Bridge.poll(SCMTriggerItem.java:124)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:528)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:574)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:119)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
In this case, polling is triggered by hitting the /notifyCommit endpoint from a GitLab webhook.
- is duplicated by
-
JENKINS-36414 Failed to record SCM polling for hudson.maven.MavenModuleSet
-
- Closed
-
- is related to
-
JENKINS-29078 hudson.triggers.Trigger$Cron doRun throwing a NullPointerException
-
- Open
-
-
JENKINS-36123 Provide a mechanism to for plugins to veto SCM polling on jobs
-
- Closed
-
I've had a look through the source code already.
SCMDecisionHandler veto = SCMDecisionHandler.firstShouldPollVeto(asItem());
if (!veto.shouldPoll(asItem())) { ...
Looks like the NPE is from using a nullable variable without first checking that it's non-null.
In fact, looking at the implementation of SCMDecisionHandler.firstShouldPollVeto, it definitely returns null when there are no handlers that veto the poll.
Not checking for null in this case is ... not great.