-
Bug
-
Resolution: Fixed
-
Major
Given I am Jenkins administrator when I create a job like the following:
node {
echo "test"
input id: 'Edebd25a79a1ac52da788eba9a7fcc3a', message: 'hey!', ok: 'yo', submitter: 'foobar' parameters: []
}
... I'm not able to answer the question it asks as I get an error saying "You need to be foobar to submit this" and I'm unable to stop/kill the job (it just doesn't work).
Probably there should be special permission for admins to stop such jobs and/or the plugin should check if the submitter is a real person when saving/running the job.
I'm using Jenkins ver. 1.596 and workflow plugin v1.1
- is related to
-
JENKINS-25550 Hard kill
-
- Resolved
-
[JENKINS-26363] Input step should permit cancellation from anyone with build abort permission
Another issue worth noticing here (probably it will be closed automagically when the above is fixed):
After I've got the described situation when I can't cancel the job running when I delete the job it disappears from the list of jobs but it is still marked as running in the list of build executors. I believe it should disappear from it when the job is deleted.
BTW in this case the workaround does not work:
- when I first click on running job the page appears and I'm able to append doDelete and click POST
- after that the running job still appears in the list of executors but if I click on it I get 404
when I delete the job it disappears from the list of jobs but it is still marked as running in the list of build executors
A distinct bug, though I am not going to fix it, since JENKINS-25550 is the better fix for the future. (You are not even supposed to be allowed to delete a running build, which is why there is no UI link to do so, but doDelete in Jenkins core does not enforce this check.)
Anyway: just restart Jenkins and the bad build should get cleaned up.
I also noticed that while you get a proper error message from /job/…/…/input/ (You need to be … to submit this), from /job/…/…/console clicking Abort does nothing. It should print the error to the build log.
Code changed in jenkins
User: tfennelly
Path:
aggregator/src/test/java/org/jenkinsci/plugins/workflow/steps/input/InputStepTest.java
support/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution.java
http://jenkins-ci.org/commit/workflow-plugin/85c610870b3611c81c20d46de73670f0ab39a7be
Log:
[FIXED JENKINS-26363 Input step should permit cancellation from anyone with Job.CANCEL permission]
Code changed in jenkins
User: Jesse Glick
Path:
aggregator/src/test/java/org/jenkinsci/plugins/workflow/steps/input/InputStepTest.java
support/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStep.java
support/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution.java
http://jenkins-ci.org/commit/workflow-plugin/eaa8f80a6398c76d6f62cfe43699322abd51961c
Log:
Merge pull request #70 from tfennelly/JENKINS-26363
[FIXED JENKINS-26363] Input step should permit cancellation from anyone with Job.CANCEL permission
Compare: https://github.com/jenkinsci/workflow-plugin/compare/729984d402eb...eaa8f80a6398
Code changed in jenkins
User: Jesse Glick
Path:
CHANGES.md
http://jenkins-ci.org/commit/workflow-plugin/4a85acdaa89ad41f1e6f04984cc5481b959ef7f9
Log:
JENKINS-26363 Noting that #70 was merged.
Code changed in jenkins
User: tfennelly
Path:
aggregator/src/test/java/org/jenkinsci/plugins/workflow/steps/input/InputStepTest.java
support/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution.java
http://jenkins-ci.org/commit/pipeline-input-step-plugin/107feb436891a06c2c738171963b98fea3647883
Log:
[FIXED JENKINS-26363 Input step should permit cancellation from anyone with Job.CANCEL permission]
Originally-Committed-As: 85c610870b3611c81c20d46de73670f0ab39a7be
The bug is that anyone with cancel permission for the build overall ought to be able to cancel the input step, whether or not they match submitter.
The stop function is implemented for the input step, but just delegates to the cancellation of the input, so that does not help in your case.
Form validation should be added for submitter to check whether it is an existing user ID or external group, insofar as the SecurityRealm can give a definitive answer.