Details
-
Story
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
-
1.0-japan-m9, 1.0-pre-beta-1, 1.0-beta-1
Description
In Scope
- add the "Stop" button in the blue bar.
- Stopping should show the current result as failed
- If we need to wait for it to stop the text of the button should be "Stopping..." and the button should be disabled.
- Stop will request a "soft" stop, and after 5 seconds, a hard stop will be requested if the job has not been stopped.
- Hide this action if the developer does not have permission to use it
Attachments
Issue Links
- is blocked by
-
-
- Resolved
-
-
JENKINS-36229 API for UI to honour permissions
-
- Resolved
-
- is related to
-
-
- Resolved
-
Activity
michaelneale:
I was testing this integration for JENKINS-36973 but had started using the simpler /stop API that was not blocking. I noticed that in some cases it stopped almost immediately (perhaps for freestyle?) but in certain pipeline cases it would take a very long time (well over 10s) to stop. I assume that using a blocking call should fix that for the most part, using this style:
../stop/?blocking=true&timeOutinSecs=10
If it works as expected, a SSE should come through that should update the job and cause the "stop" button to disappear and be replaced with a "run" button. If that doesn't happen, after 10s, what should the stop button do? Revert from disabled to enabled state so the user can try again?
michaelneale just tested the blocking approach now, in most cases it's very fast (under a second) but I did see a run against a multibranch (JDL) that took about 10s. So I think the question still stands but it's probably more of an edge case.
cliffmeyers Some answers:
Permissions: yes another ticket. I believe it would be predicated on JWT (there is a backend api for it, so it can be done at some point).
On blocking call: yes many cases it would be fast, but pipeline is infamous for taking it's sweet time, hence hte timeout, which make it to a hard stop (ie 10 seconds to do it politely, then kill it). Of course, it isn't guaranteed to kill it, so in the case where you have used blocking with a timeout, and it doesn't actually stop, the stop button can rever to the enabled state and let them try again (there is nothing else we can do other than that). so yes, like you said.
Most of the time it will be good, but some steps take time to kill.
I think the approach you have suggested is good, and if people don't like it, we review in the future.
jamesdumay would the permissions part of this ticket be out of scope? I don't believe the mechanism to get them exists yet?