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

buildWithParameters doesn't redirect to the build page

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • None

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

          [JENKINS-22865] buildWithParameters doesn't redirect to the build page

          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?

          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?

          Krip 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.

          Krip 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.

          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.

          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 .

          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.

          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.

          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.

          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.

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

          Sergey Arbuzov added a comment - /build demand all paramerers in json format So html form can not be hepl full here

          Jose Camacho added a comment -

          Any solution/update or Workaround?

          Jose Camacho added a comment - Any solution/update or Workaround?

          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.

          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.

          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.

          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.

          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().

          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().

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

              Created:
              Updated: