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.

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

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.

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

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.

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.

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

/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

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.

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.

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