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

cause not working in parameterized projects

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      The documentation in trigger builds remotely says

      Optionally append &cause=Cause+Text to provide text that will be included in the recorded build cause.

      The cause doesn't work for parameterized builds.

      Also the documentation should state that the trigger URL in that case has buildWithParameters not build...

      Already requested in wiki

        Attachments

          Activity

          Hide
          danielbeck Daniel Beck added a comment -

          The job MUST have a `token` assigned

          This feature only exists for triggering builds via token and nowhere else, which is why it is part of that feature's documentation. Adding it elsewhere would be a feature request.

          Show
          danielbeck Daniel Beck added a comment - The job MUST have a `token` assigned This feature only exists for triggering builds via token and nowhere else, which is why it is part of that feature's documentation. Adding it elsewhere would be a feature request.
          Hide
          cvijayan Colathur Vijayan added a comment -

          My intent is to figure out if there is a way to monitor a job invocation accurately by either using the Queue ID returned as part of the Location and then retrieving the Build ID  OR by passing a unique identifier to the Cause parameter.

          What I find weird is that when there is a Quiet period in effect neither the Queue ID nor the Cause parameter behave as expected. Please see the attached sample test harness and its output. 

          There are 3 jobs invoked in parallel each a unique identifier for cause. This is is the outcome.

          A. First job gets a successful build, the other 2 don't (presumably because of the Quiet period).

          B.  The First job is queryable through the Queue ID and the response does have the unique identifier passed in Cause. 

          C. However the second and third invocations get a status of 201 and have the same Queue ID of the first, with the response having all the 3 causes. 

           

            

          Show
          cvijayan Colathur Vijayan added a comment - My intent is to figure out if there is a way to monitor a job invocation accurately by either using the Queue ID returned as part of the Location and then retrieving the Build ID  OR by passing a unique identifier to the Cause parameter. What I find weird is that when there is a Quiet period in effect neither the Queue ID nor the Cause parameter behave as expected. Please see the attached sample test harness and its output.  There are 3 jobs invoked in parallel each a unique identifier for cause. This is is the outcome. A. First job gets a successful build, the other 2 don't (presumably because of the Quiet period). B.  The First job is queryable through the Queue ID and the response does have the unique identifier passed in Cause.  C. However the second and third invocations get a status of 201 and have the same Queue ID of the first, with the response having all the 3 causes.      
          Hide
          cvijayan Colathur Vijayan added a comment -

          Should I open a new ticket or reopen this ticket  ?

          Show
          cvijayan Colathur Vijayan added a comment - Should I open a new ticket or reopen this ticket  ?
          Hide
          danielbeck Daniel Beck added a comment -

          The behavior described above is as designed, queue items are combined when they're considered identical, and causes combined as well. So if you pass the same build parameters (the Magic "cause" is not one of them) they will be combined.

          Show
          danielbeck Daniel Beck added a comment - The behavior described above is as designed, queue items are combined when they're considered identical, and causes combined as well. So if you pass the same build parameters (the Magic "cause" is not one of them) they will be combined.
          Hide
          cvijayan Colathur Vijayan added a comment - - edited

          In the above case when the queue items are combined is there any way to know that they are combined from the response when they are invoked ?  All of them return a http status code of 201 (= Resource Created), so for sure this doesn't help.

           

           

          Show
          cvijayan Colathur Vijayan added a comment - - edited In the above case when the queue items are combined is there any way to know that they are combined from the response when they are invoked ?  All of them return a http status code of 201 (= Resource Created), so for sure this doesn't help.    

            People

            • Assignee:
              mindless Alan Harder
              Reporter:
              anshnd anshnd
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: