Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-12827

api should return the build number that was queued.

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: core
    • Labels:
    • Similar Issues:

      Description

      I second this. It would be really nice to see the actual build number created in the response somewhere when using the api build and buildWithParameters calls. We can try to figure it out based on the nextBuildNumber, plus parsing through the queue/api/xml output, but it is not guaranteed.

        Attachments

          Issue Links

            Activity

            Hide
            danielbeck Daniel Beck added a comment -

            Build numbers don't get assigned to queued builds, and for good reason: Between QueueSorter, QueueTaskDispatcher, and plugins like Set Next Build Number, this is impossible to determine before actually starting the build. Then there's the issue of canceling queue items – they don't (and shouldn't) use up build numbers, which this change would necessitate (or result in wrong results, as a specific build number could be queued and canceled again multiple times).

            However, there's an easy API solution that considers that issue when triggering builds.

            Trigger the build and check the headers:

            $ curl -i --netrc http://jenkins/job/triggerable-remotely/build?token=ABC
            HTTP/1.1 201 Created
            Date: Wed, 21 May 2014 16:37:58 GMT
            Server: Jetty(8.y.z-SNAPSHOT)
            Location: http://jenkins/queue/item/25/
            Content-Length: 0
            Connection: close
            Content-Type: text/plain; charset=UTF-8

            Get the Location value, and check its API at e.g. /queue/item/25/api/xml (formatted for readability):

            <waitingItem>
            	<action>
            		<cause>
            			<shortDescription>Started by remote host xxx.xxx.xxx.xxx</shortDescription>
            		</cause>
            	</action>
            	<blocked>false</blocked>
            	<buildable>false</buildable>
            	<id>25</id>
            	<inQueueSince>1400690278070</inQueueSince>
            	<params/>
            	<stuck>false</stuck>
            	<task>
            		<name>triggerable-remotely</name>
            		<url>http://jenkins/job/triggerable-remotely/</url>
            		<color>blue</color>
            	</task>
            	<url>queue/item/25/</url>
            	<why>In the quiet period. Expires in 38 sec</why>
            	<timestamp>1400690328070</timestamp>
            </waitingItem>

            This contains all the information you could possibly want here. And once the build starts and a build number has finally been assigned, you get the build number and build URL:

            <leftItem>
            	<action>
            		<cause>
            			<shortDescription>Started by remote host xxx.xxx.xxx.xxx</shortDescription>
            		</cause>
            	</action>
            	<blocked>false</blocked>
            	<buildable>false</buildable>
            	<id>25</id>
            	<inQueueSince>1400690278070</inQueueSince>
            	<params/>
            	<stuck>false</stuck>
            	<task>
            		<name>triggerable-remotely</name>
            		<url>http://jenkins/job/triggerable-remotely/</url>
            		<color>blue_anime</color>
            	</task>
            	<url>queue/item/25/</url>
            	<cancelled>false</cancelled>
            	<executable>
            		<number>6</number>
            		<url>http://jenkins/job/triggerable-remotely/6/</url>
            	</executable>
            </leftItem>

            As this feature is at least next to impossible to implement in a backwards compatible way, and has an easy, complete solution already, I'm resolving this as Won't Fix.

            Show
            danielbeck Daniel Beck added a comment - Build numbers don't get assigned to queued builds, and for good reason: Between QueueSorter, QueueTaskDispatcher, and plugins like Set Next Build Number, this is impossible to determine before actually starting the build. Then there's the issue of canceling queue items – they don't (and shouldn't) use up build numbers, which this change would necessitate (or result in wrong results, as a specific build number could be queued and canceled again multiple times). However, there's an easy API solution that considers that issue when triggering builds. Trigger the build and check the headers: $ curl -i --netrc http: //jenkins/job/triggerable-remotely/build?token=ABC HTTP/1.1 201 Created Date: Wed, 21 May 2014 16:37:58 GMT Server: Jetty(8.y.z-SNAPSHOT) Location: http: //jenkins/queue/item/25/ Content-Length: 0 Connection: close Content-Type: text/plain; charset=UTF-8 Get the Location value, and check its API at e.g. /queue/item/25/api/xml (formatted for readability): <waitingItem> <action> <cause> <shortDescription>Started by remote host xxx.xxx.xxx.xxx</shortDescription> </cause> </action> <blocked> false </blocked> <buildable> false </buildable> <id>25</id> <inQueueSince>1400690278070</inQueueSince> <params/> <stuck> false </stuck> <task> <name>triggerable-remotely</name> <url>http: //jenkins/job/triggerable-remotely/</url> <color>blue</color> </task> <url>queue/item/25/</url> <why>In the quiet period. Expires in 38 sec</why> <timestamp>1400690328070</timestamp> </waitingItem> This contains all the information you could possibly want here. And once the build starts and a build number has finally been assigned, you get the build number and build URL: <leftItem> <action> <cause> <shortDescription>Started by remote host xxx.xxx.xxx.xxx</shortDescription> </cause> </action> <blocked> false </blocked> <buildable> false </buildable> <id>25</id> <inQueueSince>1400690278070</inQueueSince> <params/> <stuck> false </stuck> <task> <name>triggerable-remotely</name> <url>http: //jenkins/job/triggerable-remotely/</url> <color>blue_anime</color> </task> <url>queue/item/25/</url> <cancelled> false </cancelled> <executable> <number>6</number> <url>http: //jenkins/job/triggerable-remotely/6/</url> </executable> </leftItem> As this feature is at least next to impossible to implement in a backwards compatible way, and has an easy, complete solution already, I'm resolving this as Won't Fix.
            Hide
            danielbeck Daniel Beck added a comment -

            JENKINS-16827: Jenkins tries to guess the build number before it can be determined, gets it wrong, and it's (correctly) reported as a bug.

            Show
            danielbeck Daniel Beck added a comment - JENKINS-16827 : Jenkins tries to guess the build number before it can be determined, gets it wrong, and it's (correctly) reported as a bug.
            Hide
            pwaterz Patrick Waters added a comment -

            I'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?

            Show
            pwaterz Patrick Waters added a comment - I'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?
            Hide
            danielbeck Daniel Beck added a comment -

            That's a different request (queue items may be too short lived, and fixing that alone may be sufficient for you), so please file a new request. You can link it to this one via More Actions » Link to declare it related.

            Show
            danielbeck Daniel Beck added a comment - That's a different request (queue items may be too short lived, and fixing that alone may be sufficient for you), so please file a new request. You can link it to this one via More Actions » Link to declare it related.
            Hide
            rusty Russell Weber added a comment - - edited

            I am vexed by the same problem. However, rather than re-open this issue, I opened the following bug:
            https://issues.jenkins-ci.org/browse/JENKINS-31039

            Show
            rusty Russell Weber added a comment - - edited I am vexed by the same problem. However, rather than re-open this issue, I opened the following bug: https://issues.jenkins-ci.org/browse/JENKINS-31039

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              jimsearle Jim Searle
              Votes:
              8 Vote for this issue
              Watchers:
              20 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: