Details
-
Bug
-
Status: Resolved (View Workflow)
-
Blocker
-
Resolution: Fixed
-
jenkins is running v2.7.4 on Mac os 10.11.6/JDK 8_102
Description
I am trying to create a Pipeline job for a github project and while configuring the Build Trigger with a Build Github Pull Request the Save is causing a NPE.
In the pipeline I have provided the git project URL and PR trigger with a Cron tabline of '* * * * *' and trigger mode 'CRON with persisted data'. I tried varying the trigger mode and cron tabline settings but I always get the NPE.
As an experiment, I created a new Freestyle project and I noticed that for the style of project one is presented with the 'Source Code Management' block where one picks the repo and credentials, as well as the git project URL and the githhub pull request parameters. I am able to save that project.
For the pipeline job the git repo is being clone in the pipeline code.
Attachments
Issue Links
- relates to
-
-
- Reopened
-
Activity
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.
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.