• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None

      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

          [JENKINS-7004] cause not working in parameterized projects

          anshnd added a comment -

          assigning to parameters and not to unrelated parameterized-trigger

          anshnd added a comment - assigning to parameters and not to unrelated parameterized-trigger

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java
          trunk/hudson/main/core/src/main/java/hudson/model/ParametersDefinitionProperty.java
          trunk/hudson/main/core/src/main/resources/hudson/model/BuildAuthorizationToken/config.jelly
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/33032
          Log:
          [FIXED JENKINS-7004] Make /buildWithParameters support remote cause and
          user supplied cause text for build via authentication token, just as /build does.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java trunk/hudson/main/core/src/main/java/hudson/model/ParametersDefinitionProperty.java trunk/hudson/main/core/src/main/resources/hudson/model/BuildAuthorizationToken/config.jelly trunk/www/changelog.html http://jenkins-ci.org/commit/33032 Log: [FIXED JENKINS-7004] Make /buildWithParameters support remote cause and user supplied cause text for build via authentication token, just as /build does.

          Adam Monsen added a comment -

          FYI, it appears cause must follow token in the query string or cause is discarded. For example:

          ?token=x&cause=y

          works, but

          ?cause=y&token=x

          discards cause.

          Adam Monsen added a comment - FYI, it appears cause must follow token in the query string or cause is discarded. For example: ?token=x&cause=y works, but ?cause=y&token=x discards cause .

          victor maslov added a comment -

          Probably I have similar issue when passing credentials via base auth, not token.

          victor maslov added a comment - Probably I have similar issue when passing credentials via base auth, not token.

          jerry wiltse added a comment - - edited

          We've done some testing and reviewed the commits, and the Cause field does not seem to be fully supported on parameterized builds.   As nakilon has said, the `cause` field does not work at all when using http auth via header or URL.  The job MUST have a `token` assigned, and as amonsen has said, it MUST come before the `cause` parameter.

          I suggest reopening this ticket.

          jerry wiltse added a comment - - edited We've done some testing and reviewed the commits, and the Cause field does not seem to be fully supported on parameterized builds.   As nakilon has said, the `cause` field does not work at all when using http auth via header or URL.  The job MUST have a `token` assigned, and as amonsen has said, it MUST come before the `cause` parameter. I suggest reopening this ticket.

          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.

          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.

          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. 

           

            

          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.      

          Should I open a new ticket or reopen this ticket  ?

          Colathur Vijayan added a comment - Should I open a new ticket or reopen this ticket  ?

          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.

          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.

          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.

           

           

          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.    

            mindless Alan Harder
            anshnd anshnd
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: