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