Observed in a test against 1.480:
… hudson.model.Executor run
SEVERE: Unexpected executor death
java.lang.NullPointerException
at hudson.model.Computer.getNode(Computer.java:473)
at hudson.slaves.SlaveComputer.getNode(SlaveComputer.java:177)
at hudson.slaves.SlaveComputer.getRetentionStrategy(SlaveComputer.java:609)
at hudson.slaves.SlaveComputer.taskCompleted(SlaveComputer.java:285)
at hudson.model.queue.WorkUnitContext.synchronizeEnd(WorkUnitContext.java:140)
at hudson.model.Executor.run(Executor.java:253)
A truly conforming servlet 3.0 container does not allow us to set "secure cookie" flag beyond ServletContextListener.onInitialized().
If we see that, don't scare the users.
- If there are any files in `$JENKINS_HOME/update-center-rootCAs` that are not ending in `.txt` and are
not valid certificates, do not blow up the entire certificate checking (and hence the ability to see updates
or tool installers) but rather ignore those files and warn the user that the file should not be there.
The correct thing to do is only use as trusted certificates those certificates that parse.
- Also fix resource leak
This changes prevents the improper usage of method without the preliminary supportsMakeDisabled() check.
As an example, Subversion plugin behaves in such way (JENKINS-24341)
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
For example, the following should not cause Run.onLoad itself to fail:
java.lang.NullPointerException
at org.jenkinsci.plugins.workflow.steps.input.InputAction.onLoad(InputAction.java:29)
at hudson.model.Run.onLoad(Run.java:342)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.onLoad(WorkflowRun.java:332)
java.lang.RuntimeException: Unable to copy /…/jobs/…/config.xml
at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewHistoryEntryAndCopyConfig(FileHistoryDao.java:252)
at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewItem(FileHistoryDao.java:238)
at hudson.plugins.jobConfigHistory.JobConfigHistoryJobListener.onCreated(JobConfigHistoryJobListener.java:31)
at hudson.model.listeners.ItemListener.fireOnCreated(ItemListener.java:161)
at jenkins.model.Jenkins.putItem(Jenkins.java:2483)
at …
Caused by: java.io.FileNotFoundException: /…/jobs/…/config.xml (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at hudson.plugins.jobConfigHistory.FileHistoryDao.copyConfigFile(FileHistoryDao.java:178)
at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewHistoryEntryAndCopyConfig(FileHistoryDao.java:250)
... 108 more
java.lang.NullPointerException
at hudson.model.User.idStrategy(User.java:140)
at hudson.model.User.getOrCreate(User.java:373)
at hudson.model.User.get(User.java:366)
at hudson.model.User.get(User.java:331)
at hudson.model.User.get(User.java:441)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.getAuthentication(CpsFlowExecution.java:614)
at org.jenkinsci.plugins.workflow.cps.CpsVmThread.run(CpsVmThread.java:20)
By converting several optionalBlock entries to use inline="true", we convert the submitted JSON from:
"hasPropertyFoo": {
"propertyFoo": "value"
},
which is a somewhat unnatural naming scheme, to:
"hasPropertyFoo": true,
"propertyFoo": "value",
This enables us to use the pattern:
if(json.optBoolean("hasPropertyFoo", json.has("propertyFoo"))) {
...
}
To permit either of the following as JSON blobs, for specifying a value for "propertyFoo":
1) "hasPropertyFoo": true, # What comes through from jelly
"propertyFoo": "value",
2) "propertyFoo": "value",
It also allows any of the following as JSON blobs, for NOT specifying a value for "propertyFoo":
3) "hasPropertyFoo": false, # What comes through from jelly
"propertyFoo": "value",
4) "hasPropertyFoo": false,
5) (nothing specified)
NOTE: The main interest in flexibility in what JSON comes through is in support of: https://wiki.jenkins-ci.org/display/JENKINS/YAML+Project+Plugin, this is also the purpose of the couple renames that are mixed in with this.
NOTE: The discrepancy between inline-optionalBlock and f:entry/f:checkbox is the text alignment, which optionalBlock keeps consistent with other elements (and what is done for these today).
This change shifts the way a number of form elements are accessed when handling AbstractProject's doConfigSubmit from using "req.getParameter(...)" style access to using JSON-style (structured form submission) access through "reg.getSubmittedForm()".
The change prevents the issue when Jenkins merges builds with different files coming from one source (It may happen!).
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
Also sending the exception to the log, which is where plugin developers expect to see it.
(This is also necessary for the exception to be visible say from configRoundtrip in a functional test.
Otherwise you just see a FailingHttpStatusCodeException due to the 400 error code, with no details.)
Might actually suffice to just throw a ServletException wrapping the exception up the chain,
letting Stapler or the container handle it, but this change is more conservative.
Jesse Glick