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

buildWithParameters doesn't redirect to the build page

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reopened (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      In version 1.561, POST request for /buildWithParameters doesn't redirect to the build page like it did until 1.560.

        Attachments

          Issue Links

            Activity

            Hide
            danielbeck Daniel Beck added a comment -

            There was a deliberate change to the behavior of buildWithParameters in Jenkins 1.561, see linked issue and changelog.

            What exactly is the problem here? Could you provide steps to reproduce the issue, what the expected result should be, and what the actual result is? Right now, it's unclear whether this is due to the deliberate change or some unexpected side effect you're reporting.

            Show
            danielbeck Daniel Beck added a comment - There was a deliberate change to the behavior of buildWithParameters in Jenkins 1.561, see linked issue and changelog. What exactly is the problem here? Could you provide steps to reproduce the issue, what the expected result should be, and what the actual result is? Right now, it's unclear whether this is due to the deliberate change or some unexpected side effect you're reporting.
            Hide
            danielbeck Daniel Beck added a comment -

            No response to comment asking for clarification in half a year, so resolving as Incomplete.

            Show
            danielbeck Daniel Beck added a comment - No response to comment asking for clarification in half a year, so resolving as Incomplete.
            Hide
            orgads Orgad Shaneh added a comment -

            Sorry for the late response. I didn't notice the previous comment.

            In my use-case, I have a web form with action=.../buildWithParameters target=_blank and method=post. I expect that when the form is submitted and the new tab is opened, that it won't be blank, but will be redirected to either the newly created job or if that's not possible (because the job hasn't started yet) to the project page.

            Show
            orgads Orgad Shaneh added a comment - Sorry for the late response. I didn't notice the previous comment. In my use-case, I have a web form with action=.../buildWithParameters target=_blank and method=post. I expect that when the form is submitted and the new tab is opened, that it won't be blank, but will be redirected to either the newly created job or if that's not possible (because the job hasn't started yet) to the project page.
            Hide
            danielbeck Daniel Beck added a comment -

            /buildWithParameters is the programmatic API endpoint. It sends a Location header value specifying the location of the queue item with information about the queued job. So the behavior you're seeing is intentional.

            You may be able to make /build work.

            Show
            danielbeck Daniel Beck added a comment - /buildWithParameters is the programmatic API endpoint. It sends a Location header value specifying the location of the queue item with information about the queued job. So the behavior you're seeing is intentional. You may be able to make /build work.
            Hide
            columbusmonkey Gavin Shelley added a comment -

            2 things to mention here :-

            1) I'm sure the /buildWithParameters used to work and successfully redirected to the job page, so useful behaviour was lost (I get asked for it back every week or so)

            2) The patch in the linked issue seems to try and include a redirect, so is it trying to do what this issue asks for and failing, or am I reading it wrong?

            Show
            columbusmonkey Gavin Shelley added a comment - 2 things to mention here :- 1) I'm sure the /buildWithParameters used to work and successfully redirected to the job page, so useful behaviour was lost (I get asked for it back every week or so) 2) The patch in the linked issue seems to try and include a redirect, so is it trying to do what this issue asks for and failing, or am I reading it wrong?
            Hide
            krissap Chris J added a comment - - edited

            Totally agree with what Gavin said.
            Would be great if we could get the previous behaviour back.

            I am often asked questions about this issue too.
            Thanks to re-consider the treatment of this regression.

            Show
            krissap Chris J added a comment - - edited Totally agree with what Gavin said. Would be great if we could get the previous behaviour back. I am often asked questions about this issue too. Thanks to re-consider the treatment of this regression.
            Hide
            danielbeck Daniel Beck added a comment -

            1) I'm sure the /buildWithParameters used to work and successfully redirected to the job page, so useful behaviour was lost (I get asked for it back every week or so)

            https://xkcd.com/1172/

            2) The patch in the linked issue seems to try and include a redirect, so is it trying to do what this issue asks for and failing, or am I reading it wrong?

            While it sends a Location header, it responds with HTTP 201 Created, instead of an HTTP 30x redirect. So it doesn't indicate where to navigate next, but which queue item was creates as a response to the request.


            Still nobody explained what's wrong with using /build. It works for the 'Build with Parameters' page in Jenkins, after all. I guarantee that this won't even be considered if you cannot explain in detail what's wrong with /build.

            Show
            danielbeck Daniel Beck added a comment - 1) I'm sure the /buildWithParameters used to work and successfully redirected to the job page, so useful behaviour was lost (I get asked for it back every week or so) https://xkcd.com/1172/ 2) The patch in the linked issue seems to try and include a redirect, so is it trying to do what this issue asks for and failing, or am I reading it wrong? While it sends a Location header, it responds with HTTP 201 Created, instead of an HTTP 30x redirect. So it doesn't indicate where to navigate next, but which queue item was creates as a response to the request. Still nobody explained what's wrong with using /build . It works for the 'Build with Parameters' page in Jenkins, after all. I guarantee that this won't even be considered if you cannot explain in detail what's wrong with /build .
            Hide
            columbusmonkey Gavin Shelley added a comment -

            /build requires the users to specify all the parameters themselves, and then an extra click to submit.

            /buildwithparameters allows us to have a dashboard with many different GET links that allow the user to run a variety of jobs with different parameters with just one click – that then easily allowed the user to follow the console output. It's a small thing, but it was used a fair bit.

            Thanks for the clarification on the redirect code.

            Show
            columbusmonkey Gavin Shelley added a comment - /build requires the users to specify all the parameters themselves, and then an extra click to submit. /buildwithparameters allows us to have a dashboard with many different GET links that allow the user to run a variety of jobs with different parameters with just one click – that then easily allowed the user to follow the console output. It's a small thing, but it was used a fair bit. Thanks for the clarification on the redirect code.
            Hide
            danielbeck Daniel Beck added a comment -

            /build requires the users to specify all the parameters themselves, and then an extra click to submit.

            Build an HTML form similar to the /build page, but with hidden parameters. It'll no longer be one link, but one button.

            Show
            danielbeck Daniel Beck added a comment - /build requires the users to specify all the parameters themselves, and then an extra click to submit. Build an HTML form similar to the /build page, but with hidden parameters. It'll no longer be one link, but one button.
            Hide
            whitediver Sergey Arbuzov added a comment -

            /build demand all paramerers in json format
            So html form can not be hepl full here

            Show
            whitediver Sergey Arbuzov added a comment - /build demand all paramerers in json format So html form can not be hepl full here
            Hide
            jose_camacho Jose Camacho added a comment -

            Any solution/update or Workaround?

            Show
            jose_camacho Jose Camacho added a comment - Any solution/update or Workaround?
            Hide
            jkinred Jonathan Kinred added a comment -

            Here is a working HTML form for Jenkins 2.89.4:

            <form method='post' action='/job/sine-deploy/build'>
              <input name='json' type='hidden' value="{'parameter': {'name': 'TRIGGERED_FROM_BUILD', 'runId': '${JOB_NAME}#${BUILD_NUMBER}'}, 'statusCode': '303', 'redirectTo': '/job/sine-deploy/'}" />
              <input name='Submit' type='submit' value='Deploy' class='submit-button primary' />
            </form>
            

            Here it is used within a script block in a declarative pipeline, adding a "Deploy" button to the left hand build history list which triggers the job then takes the user to the target job page – in this case the target build has a "Run Parameter" configured and Jenkins has Safe HTML enabled:

                pipeline {
                  agent any
                  stages {
                    stage('Sample') {
                      steps {
                        sh 'echo "Sample"'
                      }
                    }
                    post {
                      success {
                        script {
                          currentBuild.description = "<form method='post' action='/job/sine-deploy/build'><input name='json' type='hidden' value=\"{'parameter': {'name': 'TRIGGERED_FROM_BUILD', 'runId': '${JOB_NAME}#${BUILD_NUMBER}'}, 'statusCode': '303', 'redirectTo': '/job/sine-deploy/'}\" /><input name='Submit' type='submit' value='Deploy' class='submit-button primary' /></form>"
                        }
                      }
                    }
                  }
                }
            

             

            If you want specifics on how to modify the form for your own job, go to the buildWithParameters page and use your browsers inspector to inspect a submission.

            Show
            jkinred Jonathan Kinred added a comment - Here is a working HTML form for Jenkins 2.89.4: <form method='post' action='/job/sine-deploy/build'> <input name='json' type='hidden' value="{'parameter': {'name': 'TRIGGERED_FROM_BUILD', 'runId': '${JOB_NAME}#${BUILD_NUMBER}'}, 'statusCode': '303', 'redirectTo': '/job/sine-deploy/'}" /> <input name='Submit' type='submit' value='Deploy' class='submit-button primary' /> </form> Here it is used within a script block in a declarative pipeline, adding a "Deploy" button to the left hand build history list which triggers the job then takes the user to the target job page – in this case the target build has a "Run Parameter" configured and Jenkins has Safe HTML enabled: pipeline { agent any stages { stage('Sample') { steps { sh 'echo "Sample"' } } post { success { script { currentBuild.description = "<form method='post' action='/job/sine-deploy/build'><input name='json' type='hidden' value=\"{'parameter': {'name': 'TRIGGERED_FROM_BUILD', 'runId': '${JOB_NAME}#${BUILD_NUMBER}'}, 'statusCode': '303', 'redirectTo': '/job/sine-deploy/'}\" /><input name='Submit' type='submit' value='Deploy' class='submit-button primary' /></form>" } } } } }   If you want specifics on how to modify the form for your own job, go to the buildWithParameters page and use your browsers inspector to inspect a submission.
            Hide
            ringerc Craig Ringer added a comment -

            That's useful, but doesn't negate the original concern at all.

            You can't easily form a dynamic json string for submitting to /build by accepting user input from form fields. It's a usable workaround when everything you want is known at job-completion time. But sometimes you want to prefill most parameters, but allow some to be adjusted. That doesn't seem to be possible with your approach unless you're able to enable JavaScript and build some json on the fly from the form input fields.

            Allowing buildWithParameters to redirect to the job afterwards seems like a low-cost solution, perhaps with a redirectToJob=1 param you can make a hidden input. So you can still have your nice custom form, prefilled with most of the params you want to forward to the new job, and you can let the user modify some params before submit.

            AFAICS to work around this you need JavaScript to submit without navigating to the empty result page, then to redirect to the new job after a delay.

            Show
            ringerc Craig Ringer added a comment - That's useful, but doesn't negate the original concern at all. You can't easily form a dynamic json string for submitting to /build by accepting user input from form fields. It's a usable workaround when everything you want is known at job-completion time. But sometimes you want to prefill most parameters, but allow some to be adjusted. That doesn't seem to be possible with your approach unless you're able to enable JavaScript and build some json on the fly from the form input fields. Allowing buildWithParameters to redirect to the job afterwards seems like a low-cost solution, perhaps with a redirectToJob=1 param you can make a hidden input. So you can still have your nice custom form, prefilled with most of the params you want to forward to the new job, and you can let the user modify some params before submit. AFAICS to work around this you need JavaScript to submit without navigating to the empty result page, then to redirect to the new job after a delay.
            Hide
            ringerc Craig Ringer added a comment - - edited

            This is puzzling - in `ParametersDefinitionProperty.java` I see the `buildWithParameters` method emitting a redirect to the job if `Queue.schedule2` produces an item. Which AFAICS it should unless there's one already present.

            https://github.com/jenkinsci/jenkins/blob/0795e89b308ec7fcbda097858d58763d8531be8c/core/src/main/java/hudson/model/ParametersDefinitionProperty.java#L179

            Nonetheless, it doesn't seem to, even if I pass `delay` of `0sec`. It looks like that's because the HTTP status code is SC_CREATED, which is a 200-series code, not a 300-series redirect. Sensible for an xmlhttprequest-style javascript submit, not helpful for a form submit.

            The json-blob approach has other issues. You need to produce a suitable runId. You need to deal with the XSRF protection crumbs. It looks messy.

            Seems to me that /build should just accept a POST with the same format as buildWithParameters and an optional "useAsDefaults" that displays the UI and lets the user confirm. Either way, redirecting to the submitted job after. I'll see if I can hack together a patch for that but I'm still having a hard time getting my head around the inner workings of Jenkins.

            See also https://wiki.jenkins.io/display/JENKINS/Structured+Form+Submission for an explanation of why Jenkins does things this way, and see hudson-behaviour.js buildFormTree().

            Show
            ringerc Craig Ringer added a comment - - edited This is puzzling - in `ParametersDefinitionProperty.java` I see the `buildWithParameters` method emitting a redirect to the job if `Queue.schedule2` produces an item. Which AFAICS it should unless there's one already present. https://github.com/jenkinsci/jenkins/blob/0795e89b308ec7fcbda097858d58763d8531be8c/core/src/main/java/hudson/model/ParametersDefinitionProperty.java#L179 Nonetheless, it doesn't seem to, even if I pass `delay` of `0sec`. It looks like that's because the HTTP status code is SC_CREATED, which is a 200-series code, not a 300-series redirect. Sensible for an xmlhttprequest-style javascript submit, not helpful for a form submit. The json-blob approach has other issues. You need to produce a suitable runId. You need to deal with the XSRF protection crumbs. It looks messy. Seems to me that /build should just accept a POST with the same format as buildWithParameters and an optional "useAsDefaults" that displays the UI and lets the user confirm. Either way, redirecting to the submitted job after. I'll see if I can hack together a patch for that but I'm still having a hard time getting my head around the inner workings of Jenkins. See also https://wiki.jenkins.io/display/JENKINS/Structured+Form+Submission for an explanation of why Jenkins does things this way, and see hudson-behaviour.js buildFormTree().

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              orgads Orgad Shaneh
              Votes:
              3 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated: