Jun 23, 2016 10:35:00 AM hudson.triggers.Trigger$Cron doRun
WARNING: Cron thread throw an exception
java.lang.NullPointerException
at hudson.triggers.Trigger.checkTriggers(Trigger.java:267)
at hudson.triggers.Trigger$Cron.doRun(Trigger.java:221)
at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
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)
Any cron job on the instance will work because of this issue
I would say this may not have been a defect to begin with. The plugin documentation describes the proper usage of this trigger with Job DSL. The Jenkins GUI will ensure that cron is non-null, but from a scripted client like Job DSL you are expected to define all mandatory fields. If cron is meaningfully optional in this context—some Trigger implementations do not really require it, because they have an empty run, though I think this one does—then Trigger.readResolve should set it to the empty string rather than null.
Jesse Glick It's ugly – further investigation showed that the problem is that GhprbTrigger#readResolve doesn't call super.readResolve() – which would prevent the invalid trigger from being created.