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

api should return the build number that was queued.

    XMLWordPrintable

Details

    • New Feature
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Won't Fix
    • core

    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

            jimsearle Jim Searle created issue -
            tjbiddle TJ Biddle added a comment -

            +1. Was about to post this on GG.

            Hitting /build and /buildWithParameters really needs to return some type of data so we know the call was received and kicked off properly.

            To start:

            Build Number
            Parameters
            Time until it starts (If in queue)

            I'm making calls currently and I've had it silently fail a few times and I don't have any way to tell if this is happening and try again

            tjbiddle TJ Biddle added a comment - +1. Was about to post this on GG. Hitting /build and /buildWithParameters really needs to return some type of data so we know the call was received and kicked off properly. To start: Build Number Parameters Time until it starts (If in queue) I'm making calls currently and I've had it silently fail a few times and I don't have any way to tell if this is happening and try again

            I'm also looking forward to get this feature implemented. I'm developing a ruby API client for Jenkins and many of my users have requested for this feature. Checking the nextBuildNumber and build queue may not give the correct build number. The response from Jenkins for build or buildWithParameters gives the response code of 302. It would be nice to get a JSON or XML response like

            {
            "buildNumber" : 11
            }

            this would be great.

            https://github.com/arangamani/jenkins_api_client

            arangamani Kannan Manickam added a comment - I'm also looking forward to get this feature implemented. I'm developing a ruby API client for Jenkins and many of my users have requested for this feature. Checking the nextBuildNumber and build queue may not give the correct build number. The response from Jenkins for build or buildWithParameters gives the response code of 302. It would be nice to get a JSON or XML response like { "buildNumber" : 11 } this would be great. https://github.com/arangamani/jenkins_api_client
            sogabe sogabe made changes -
            Field Original Value New Value
            Link This issue is duplicated by JENKINS-16263 [ JENKINS-16263 ]
            addepar_andy andy lei added a comment -

            +1.

            There's currently no way to know what happened to your build request without continuously monitoring the queue.

            Even if your build number wasn't directly returned, at least have a trigger timestamp or other matching field in the build details so that you can at least query the build list and determine which build corresponded to your request.

            addepar_andy andy lei added a comment - +1. There's currently no way to know what happened to your build request without continuously monitoring the queue. Even if your build number wasn't directly returned, at least have a trigger timestamp or other matching field in the build details so that you can at least query the build list and determine which build corresponded to your request.
            mlh Michael Hess added a comment -

            +1,

            We really need this as well. If someone could contact me we would be happy to sponsor it but can't use paypal.

            mlh Michael Hess added a comment - +1, We really need this as well. If someone could contact me we would be happy to sponsor it but can't use paypal.

            I'm not sure how easy it will be to add this functionality in the Jenkins API itself. As the build number is determined once the build is moved from the queue to one of the executors, it might be hard to return the build number as soon as the build is triggered. I looked around the code in Jenkins and it doesn't seem to be an easy fix. However I have authored a jenkins_api_client ruby gem which makes use of the new behavior of Jenkins' response to build POST requests.

            In recent versions, jenkins returns a location header to the response of the build POST request. This location header contains the location of the queue item for the particular build. This queue item can be continuously queried until it is placed in one of the executors. Once the queue item reaches an executor, it is assigned with a build number.

            I have implemented a neat solution here https://github.com/arangamani/jenkins_api_client/issues/88 which will optionally accept an argument on whether to return the build number and return the build number once it is obtained. The only downside is that if there aren't enough idle executors of another build for the same job is running, this call will have to wait until it obtains the build number. Which is why I made this optional so people can decide whether to wait or not.

            Any comments on my implementation would be appreciated.

            arangamani Kannan Manickam added a comment - I'm not sure how easy it will be to add this functionality in the Jenkins API itself. As the build number is determined once the build is moved from the queue to one of the executors, it might be hard to return the build number as soon as the build is triggered. I looked around the code in Jenkins and it doesn't seem to be an easy fix. However I have authored a jenkins_api_client ruby gem which makes use of the new behavior of Jenkins' response to build POST requests. In recent versions, jenkins returns a location header to the response of the build POST request. This location header contains the location of the queue item for the particular build. This queue item can be continuously queried until it is placed in one of the executors. Once the queue item reaches an executor, it is assigned with a build number. I have implemented a neat solution here https://github.com/arangamani/jenkins_api_client/issues/88 which will optionally accept an argument on whether to return the build number and return the build number once it is obtained. The only downside is that if there aren't enough idle executors of another build for the same job is running, this call will have to wait until it obtains the build number. Which is why I made this optional so people can decide whether to wait or not. Any comments on my implementation would be appreciated.
            christiank2510 Christian K. added a comment -

            Another idea for a workaround would be to make the build parametrized, e.g. with a parameter "id". On the remote side you could than generate a unique and deterministic build ID that you can later recognize in the builds XML/JSON description.

            christiank2510 Christian K. added a comment - Another idea for a workaround would be to make the build parametrized, e.g. with a parameter "id". On the remote side you could than generate a unique and deterministic build ID that you can later recognize in the builds XML/JSON description.
            docwhat Christian Höltje made changes -
            Link This issue is duplicated by JENKINS-4538 [ JENKINS-4538 ]
            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.

            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.
            danielbeck Daniel Beck made changes -
            Resolution Won't Fix [ 2 ]
            Status Open [ 1 ] Resolved [ 5 ]
            danielbeck Daniel Beck made changes -
            Link This issue is duplicated by JENKINS-5189 [ JENKINS-5189 ]
            danielbeck Daniel Beck made changes -
            Link This issue is related to JENKINS-16827 [ JENKINS-16827 ]
            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.

            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.

            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?

            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?
            pwaterz Patrick Waters made changes -
            Resolution Won't Fix [ 2 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            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.

            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.
            danielbeck Daniel Beck made changes -
            Resolution Won't Fix [ 2 ]
            Status Reopened [ 4 ] Resolved [ 5 ]
            danielbeck Daniel Beck made changes -
            Link This issue is related to JENKINS-26228 [ JENKINS-26228 ]
            sramage Steve Ramage made changes -
            Link This issue is related to JENKINS-29222 [ JENKINS-29222 ]
            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

            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
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 143285 ] JNJira + In-Review [ 190481 ]
            surenpi Rick made changes -
            Link This issue is duplicated by JENKINS-50361 [ JENKINS-50361 ]

            People

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

              Dates

                Created:
                Updated:
                Resolved: