-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
Currently, the simple-queue-plugin allows privileged users to move specific jobs to the front of the build queue via the web UI. It would be helpful to expose similar functionality via an API endpoint.
See also comments on JENKINS-1878 for a similar request.
This route would be similarly protected and only accessible to users with manage permissions.
Example:
POST /simpleMove/apiMove?moveType=A&itemId=B
The benefits of this would be:
- programmatic prioritization: Its possible to use the existing /simpleMove/move endpoint programatically, but this requires injecting a referer header
- validation: can respond with 400s when request is invalid, or 404s when queue item does not exist.
POST /simpleMove/apiMove?moveType=DOWN_FAST&itemId=-1
404 Not Found
{
"message": "Could not find item with ID -1"
}
Questions:
- Users would need to fetch ahead of time the itemId they want to move. In my case, I can retrieve this from /job/:jobName/:buildNumber/api/json. The required ID is in the queueId field, but it appears to always be one less than required by simple-queue-plugin? Ex. if the /job/:jobName/:buildNumber/api/json endpoint returns queueId 5, I can prioritize the build with /simpleMove/move?itemId=6&... Why is there a difference? Is there a better way to retrieve the itemId?
[JENKINS-66928] Ability to move build to the front of the queue via API as part of simple-queue-plugin
Garrett Randall
added a comment - Quick proof-of-concept here: https://github.com/garrandall/simple-queue-plugin
Garrett Randall
added a comment - Quick proof-of-concept here: https://github.com/garrandall/simple-queue-plugin To comment on "strange off-by-one offset" I guess you mean the different ID, than you expected right? It seems to me that those IDs are totally different numbers. Also you can get id by "/job/:jobName/:buildNumber/api/json" only for jobs that are not in the queue anymore, in my eyes. So that way is useless.
Btw why cant you use the same api as UI?
Because I tried to just go to the link that is below the image and it works even though it shows some kind of error. I would be interested where you see problem with that.
E. g. http://0.0.0.0:8080/simpleMove/move?moveType=UP&itemId=11&viewName=all
But I found the right id under "http://0.0.0.0:8080/job/C/api/json" queueItem: id:
Garrett Randall
added a comment - Hey otradovec , thanks for the response! My team figured out why this off-by-one error is happening, its an aspect of our use of jenkins where builds have multiple stages that are queued as independent queue items.
My team is interested in prioritizing all queued items related to a build. The method I've found to do that is, within the plugin expose a route that accepts jobName & buildNumber params, and prioritize all items in queue where:
item.task.url == "/job/:jobName/:buildNumber/"
For my case, this works. I'd be interested in if this could be considered as a contribution after my team has hardened it a bit more? It might not be feasible for DOWN and UP move types, but would work for DOWN_FAST and UP_FAST.
As for why I was looking to add an API route without reusing the UI route: Initially we hit the UI route programatically, which required faking our Referer header, which is fine. The primary reason I was hoping to add an API route was for better feedback on failures. The UI endpoint doesn't give any feedback if the request is invalid or the queue item doesn't exist, and for a productionized use case users would want to know about success/failure for these requests.
Garrett Randall
added a comment - Hey otradovec , thanks for the response! My team figured out why this off-by-one error is happening, its an aspect of our use of jenkins where builds have multiple stages that are queued as independent queue items.
My team is interested in prioritizing all queued items related to a build. The method I've found to do that is, within the plugin expose a route that accepts jobName & buildNumber params, and prioritize all items in queue where:
item.task.url == "/job/:jobName/:buildNumber/"
For my case, this works. I'd be interested in if this could be considered as a contribution after my team has hardened it a bit more? It might not be feasible for DOWN and UP move types, but would work for DOWN_FAST and UP_FAST.
As for why I was looking to add an API route without reusing the UI route: Initially we hit the UI route programatically, which required faking our Referer header, which is fine. The primary reason I was hoping to add an API route was for better feedback on failures. The UI endpoint doesn't give any feedback if the request is invalid or the queue item doesn't exist, and for a productionized use case users would want to know about success/failure for these requests. Regarding the last paragraph, it makes sence to create the new api for doing the same thing that is possible with UI to do without it.
From the second paragraph it seems that you want to prioritize items from certain same builds. For that there was a plugin, I am not sure about its name. Maybe it was:
https://plugins.jenkins.io/PrioritySorter/
Why dont you use that?
Also why you do not use:
https://plugins.jenkins.io/dependency-queue-plugin/
https://plugins.jenkins.io/multi-branch-priority-sorter/
I am not sure what do you mean by "could be considered as a contribution". If you mean accepting PR where there is created only new API, then I would accept it if it would look good. If the PR would try to move the items based on build from which they are created, than I would propably refuse it, since that is not point of this plugin and it would only create something like the PrioritySorter plugin.
I have been tinkering with this on a fork of simple-queue-plugin, and would potentially be interested in submitting a pull request with this functionality once it looks good, but I'm particularly interested in the question in the ticket - where does that strange off-by-one offset some from?