-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
Currently when you start a job using the api, you do get back the queue location url. This is great. But the problem is that requires me to keep checking until a build number get's assigned. I don't know what the time to live is on the queue id, but it seem short lived. So if I happen to miss it, the connection between the queue id and the job is gone forever.
What I think would be a good idea is to associated the queue id with the build id. So basically, even if the item isn't in the queue anymore, I can still lookup the job via the queue id. Or allow for a setting for min time to live on the queue. Thoughts?
Relates to JENKINS-12827
- is related to
-
JENKINS-12827 api should return the build number that was queued.
-
- Resolved
-
-
-
- Open
-
[JENKINS-26228] Allow for minimum time to live on item in queue, to ensure api consumers can connect a queue id to a job id
Patrick Waters
created issue -
Patrick Waters
made changes -
| Description |
Original:
'd like to reopen this issue, and ask for feature request. Currently when you start a job using the api, you do get back the queue location url. This is great. But the problem is that requires me to keep checking until a build number get's assigned. I don't know what the time to live is on the queue id, but it seem short lived. So if I happen to miss it, the connection between the queue id and the job is gone forever. What I think would be a good idea is to associated the queue id with the build id. So basically, even if the item isn't in the queue anymore, I can still lookup the job via the queue id. Thoughts? Relates to |
New:
Currently when you start a job using the api, you do get back the queue location url. This is great. But the problem is that requires me to keep checking until a build number get's assigned. I don't know what the time to live is on the queue id, but it seem short lived. So if I happen to miss it, the connection between the queue id and the job is gone forever. What I think would be a good idea is to associated the queue id with the build id. So basically, even if the item isn't in the queue anymore, I can still lookup the job via the queue id. Thoughts? Relates to |
Patrick Waters
made changes -
| Description |
Original:
Currently when you start a job using the api, you do get back the queue location url. This is great. But the problem is that requires me to keep checking until a build number get's assigned. I don't know what the time to live is on the queue id, but it seem short lived. So if I happen to miss it, the connection between the queue id and the job is gone forever. What I think would be a good idea is to associated the queue id with the build id. So basically, even if the item isn't in the queue anymore, I can still lookup the job via the queue id. Thoughts? Relates to |
New:
Currently when you start a job using the api, you do get back the queue location url. This is great. But the problem is that requires me to keep checking until a build number get's assigned. I don't know what the time to live is on the queue id, but it seem short lived. So if I happen to miss it, the connection between the queue id and the job is gone forever. What I think would be a good idea is to associated the queue id with the build id. So basically, even if the item isn't in the queue anymore, I can still lookup the job via the queue id. Or allow for a setting for min time to live on the queue. Thoughts? Relates to |
| Component/s | New: core [ 15593 ] | |
| Component/s | Original: queue-cleanup-plugin [ 19323 ] | |
| Issue Type | Original: New Feature [ 2 ] | New: Improvement [ 4 ] |
| Link |
New:
This issue is related to |
FWIW it's a hard-coded 300 seconds as per
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Queue.java#L199
I have some difficulty imagining this needing to be longer, but it's certainly doable, at least via the usual System property approach for Options Nobody Should Ever Need Unless In Really Weird Situations:
https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties
Would that be acceptable?
Note that a balance needs to be struck between availability for outside clients and the memory requirements for keeping data around nobody needs on very busy instances. Five minutes seems like a sane default, and a viable choice for most clients (making it far too obscure for a UI option IMO).
Patrick Waters
added a comment - Thanks for the quick response. 300 seconds does sound decent. What do you think about storing the queue id with the job id? And allow for lookup based on that? Then there isn't any issue of ever loosing the job from an outside cosumer.
Patrick Waters
added a comment - Thanks for the quick response. 300 seconds does sound decent. What do you think about storing the queue id with the job id? And allow for lookup based on that? Then there isn't any issue of ever loosing the job from an outside cosumer. My opinion? It appears to solve a problem that does not really exist with a bunch of complexity that needs to be documented and maintained.
So I think there's no point in adding it, certainly not in core. (Allowing to tweak a constant as long as it continues to be used via System property is low impact though, so that could be done.)
A plugin OTOH, and it's certainly easily possible by implementing a QueueListener that records any onLeft(Queue.LeftItem), would be a possible solution for people in a situation such as yours.
Thanks for filing an independent issue!