This occurs with the Parametrised trigger as well so it is core issue in that declared parameters are not enforced to be present. This is caused because the script and Parametrised trigger both call scheduleBuild() directly without the ParametersDefinitionProperty handling the starting parameters, as would occur if doBuild() or buildWithParameters() is called.

Pull request for a potential fix submitted

https://github.com/jenkinsci/jenkins/pull/553

Ran into the same issue with V1.513. Would really like to see this implemented.

@cjo9900 - any news on your suggested fix? I looked at the code change and it looks good to me. Is there a way to push this?

I've run into this issue as well, when trying to use the Bitbucket pull request builder plugin. That plugin sets its own parameters in scheduleBuild, so the parameters I set up for the project are not present at all on builds triggered by the plugin.

+1 larcher this is a big problem

+1 This is an impediment to using Groovy and feels unnatural.  For example, if I create a parameter which is not configured in the build, it does not appear as an ENV var, so the creation of parameters does affect your groovy code, but the choice of defaults does not.

For anyone in need of a workaround, the following can set the defaults in your groovy code:

String jobName;targetJob = myFolder.getItem(jobName);
params = [];
for (ParameterDefinition paramDefinition : targetJob.getProperty(ParametersDefinitionProperty.class).getParameterDefinitions()) \{
params += paramDefinition.getDefaultParameterValue();
\}
paramsAction = new hudson.model.ParametersAction(params)
...

Core is behaving as designed. If the Groovy Postbuild plugin wishes to offer a convenience method to build another job with with some parameters set, it can do so. That would duplicate functionality already available in Pipeline, of course.

If a Jenkins script has parameters and a defaultValue, then the Jenkins script should always honor those defaultValues.  Otherwise that script can't be relied upon.  It means lots of code to check if a property exists, even though it says there should be a defaultValue assigned.

So now you need to cope with "null" (undefined), defaultValue, and a specified value.

In my company, after every push the project is built on Jenkins.  If I want to make a release, I will then perform a Parameterized Build and set the boolean property "makeRelease" to true.  My second parameter, "tagVersion" is a string.  Currently my on-push Jenkins build is ignoring the defaultValues and breaking the build - which means I can't create a GitLab Merge Request.

This link might help https://www.cyotek.com/blog/using-parameters-with-jenkins-pipeline-builds  "Accessing parameters"

It explains that based on how you access the parameter value, you'll get different behavior., i.e. return null, or throw error.