vivek could the default behaviour of STOP try to stop it and then after 10 seconds do a hard stop? That way the frontend doesn't have to co-ordinate this.

jamesdumay Only downside of it is that by default it might take at most 10 sec or so, its sort of blocking call. So instead of blocking being default if UI can call stop api with a parameter to stop a build in blocking way with optional timeout, that might be ok? This way they don't have to deal with managing state and one call will give them complete stop behavior.

vivek I think that could be ok

So there will be a blocking api that you can specify how long you want to be blocked for?

vivek could you write up a ticket that covers what needs to be done from an API PoV?

jamesdumay would the permissions part of this ticket be out of scope? I don't believe the mechanism to get them exists yet?

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.

PR: https://github.com/jenkinsci/blueocean-plugin/pull/446