Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
Jenkins 2.257
Jenkins Master Linux
Jenkins Slave Windows
Description
${jenkins url}/queue/api/json?tree=items[id] return list of
queueID. But when I searching Job with same queueID there is no Job with same queueID.
When I open Job from the queue and check his queueID, queueID is not the same like in the queue. queueID from job is smaller like queueID from queue.
Because this bug I cannot use searching function depending queueID(
${env.JENKINS_URL}api/xml?tree=jobs[jobs[allBuilds[queueId,url,number,fullDisplayName]]]&pretty=true&depth=3&xpath=/*/job/job/allBuild[queueId=${queueID}])
example:
One job is in queue
queue:
${env.JENKINS_URL}/queue/api/json?tree=items[id]
{"_class":"hudson.model.Queue","items":[{"_class":"hudson.model.Queue$BuildableItem","id":45342}]}
job:
"id" : "1268",
"keepLog" : false,
"number" : 1268,
"queueId" : 45341,
"result" : null,
"timestamp" : 1600345253078,
Attachments
Activity
Roman Dolinsky
added a comment - My main point is the figure which jobs are in Queue. If I run e.g. 25 parallel jobs and I have only 10 free Idle, I wanna know which jobs are executing (on slaves or master) and which jobs are in a Build Queue using REST API.
My main question is why Queue ID in the job not represent same id in Build Queue.
Roman Dolinsky
added a comment - My main point is the figure which jobs are in Queue. If I run e.g. 25 parallel jobs and I have only 10 free Idle, I wanna know which jobs are executing (on slaves or master) and which jobs are in a Build Queue using REST API.
My main question is why Queue ID in the job not represent same id in Build Queue. Please use Jenkins terminology. Writing about jobs having queue IDs makes no sense, I don't understand what you're trying to say.
Markus Winter
added a comment - Are we talking about freestyle jobs or pipeline?
A BuildableItem is something that hasn't started running on an executor.
As your query for jobs (actually runs of a job) will only find runs that have already started running so you can't find it of course.
For a short time (minutes) jobs that started running stay in the queue as Queue.LeftItem.
You can use your search. It will start returning a result once the job has started running on an executor.
Markus Winter
added a comment - Are we talking about freestyle jobs or pipeline?
A BuildableItem is something that hasn't started running on an executor.
As your query for jobs (actually runs of a job) will only find runs that have already started running so you can't find it of course.
For a short time (minutes) jobs that started running stay in the queue as Queue.LeftItem.
You can use your search. It will start returning a result once the job has started running on an executor. 
Nikolai Ehrhardt
added a comment - I can confirm Romans observation.
Its still same on jenkins 2.361
No matter what job hangs in queue. The Build-Numbers queue id is inconsistent with queues id.
Nikolai Ehrhardt
added a comment - I can confirm Romans observation.
Its still same on jenkins 2.361
No matter what job hangs in queue. The Build-Numbers queue id is inconsistent with queues id. The issue as described makes no sense, because BuildableItem only exists in the queue. Only once the queue item has left the queue and started building will there be a build whose queue ID corresponds to the queue item's ID. The purpose it to let you track a build from queue item (once it's a LeftItem) to running build, but while it's still in the queue, there's no build yet, so queue IDs necessarily don't match.
And if you're trying to associate queue items with jobs (rather than builds), this is simply not the solution you're looking for.
If I have misunderstood what you're trying to do, please clarify.
Please use Jenkins terminology. Writing about jobs having queue IDs makes no sense, I don't understand what you're trying to say.
still applies.
Queue ID is for mapping queued items to the builds they become once they leave the queue.
It is unclear from your description whether this is broken, or whether you're looking at a build (from an earlier queue entry) and a queue entry (that is new) at the same time.