Yes, the configuration name is set. I think the summary of this bug is wrong. The poll SCM fails the first time it is executed with the null pointer exception (see my commment above). After a Jenkins reboot, the first poll SCM execution fails the same way. I noticed that behavior this week after some investigations. It was causing troubles in our system because this trigger is executed once per week.
FYI, I worked around the problem by adding these three line before calling compareBaseline.
if(siProject == null)
{
siProject = getIntegrityProject();
}
int changeCount = siProject.compareBaseline(projectDB, api);
I reviewed the source code of the plugin and it seems like the projects map is initialized the first time getIntegrityProject() is called by compareRemoteRevisionWith. As a consequence, siProject is set to null and there is an exception thrown:
java.lang.NullPointerException
at hudson.scm.IntegritySCM.compareRemoteRevisionWith(IntegritySCM.java:939)
at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
at hudson.scm.SCM.poll(SCM.java:373)
at hudson.model.AbstractProject._poll(AbstractProject.java:1585)
at hudson.model.AbstractProject.poll(AbstractProject.java:1494)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:462)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:491)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)