Can you attach the Pipeline script that's failing so we can reproduce this? Thanks.

I think script not need because it only how Trigger.start(job, boolean) is called. My code contains check to ensure that job is passed with right trigger and NPE caused by trigger missing in job. I can rework code, but would firstly like to see some javadoc about initialisation order that worked fine before.

Ok, I found the problem - GitHubPRTrigger.start needs the trigger to be returned from Job.getTriggers() or it barfs out, but with the JobProperty approach in WorkflowJob, Trigger.start is called in PipelineTriggersJobProperty.rebuild, which is run before Job.doConfigSubmit actually calls properties.add(someProperty)...so Job.getTriggers() doesn't include the GitHubPRTrigger on first save. Woof. That's...complicated and painful. I'll see what I can figure out.

I have attached the zip of the job that is getting the NPE. I did try to recreate the issues with a scratch Pipeline job and I did not see the NPE, so I have a workaround. The job is barebones. For me, when I go to config the job, click on Github Pull Request in trigger and and a cron of '* * * * *', then save. This is where the NPE happens for me.

Seems like a bug in the github-pullrequest plugin to me. There is an actual Trigger instance which is being asked to start, yet it calls some code which goes and tries to look itself up? Why not just pass the this reference along? I would recommend this be reassigned unless there is also some problem affecting implementations which hew to the API contract.

this is trigger but code must use fully configured job, that's logic is used for automatic hooks registration later. According to API start() is called after job was configured - that doesn't happen because WorkflowJob introduced wrong reconfigurations. job must be configured either it makes 0 sense to pass not configured job to trigger. Trigger also rely on GitHubJobProperty so if job reconfigured wrong - nothing will work right.

According to API start() is called after job was configured

I do not see anything in Javadoc specifying timing or ordering behavior here.

it makes [no] sense to pass not configured job to trigger. Trigger also rely on GitHubJobProperty

Seems like a design issue. Triggers should have self-contained configuration.

That how it worked all the time. GitHubJobProperty is shared property that used by all other plugins (especially triggers).

https://github.com/jenkinsci/workflow-job-plugin/pull/28 restores original behaviour so it would be easy to fix it back.

Code changed in jenkins
User: Andrew Bayer
Path:
src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java
src/main/java/org/jenkinsci/plugins/workflow/job/properties/PipelineTriggersJobProperty.java
src/test/java/org/jenkinsci/plugins/workflow/job/properties/PipelineTriggersJobPropertyTest.java
src/test/java/org/jenkinsci/plugins/workflow/job/properties/QueryingMockTrigger.java
src/test/resources/org/jenkinsci/plugins/workflow/job/properties/PipelineTriggersJobPropertyTest/triggerPresentDuringStart.json
http://jenkins-ci.org/commit/workflow-job-plugin/d49d3c275e5fdccdab9f126e20eb553ece847ae6
Log:
[FIXED JENKINS-38454] Make sure we add the triggers before starting.

This was...complex. But it works. We make sure the triggers property
has been added before starting, in case the start method for a trigger
class expects the trigger to already be present on the job. Existing
tests all pass, and the new test failed without the changes to
WorkflowJob and PipelineTriggersJobProperty. Phew.

Note - I'm working on getting rid of the need for posting hardcoded
JSON and just using form manipulation.