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

default parameter values are ignored when triggering parameterized build from groovy post-build script

    Details

    • Similar Issues:

      Description

      Steps to reproduce:

      1. create job Foo with two string parameters: MAJOR, with default value '1', MINOR, with default value '0'
      2. create job Bar with a groovy post-build hook thus:

        def params = []
        params.push( new StringParameterValue( 'MINOR', 2 ) )
        def foo = manager.hudson.getJob( 'Foo' )
        foo.scheduleBuild( 2, new Cause.UpstreamCause( manager.build ), new ParametersAction( params ) )
      

      3. build Bar

      Expected Result:

      Foo builds with parameter values MAJOR=1, MINOR=2

      Actual Result:

      Foo build with parameter values MINOR=2

      If MAJOR isn't specified in the parameter list when invoking the build, it should use the default value in Foo's configuration. Instead, the parameter isn't evaluated at all.

        Attachments

          Issue Links

            Activity

            Hide
            nightwolfzor Night Wolf added a comment -

            +1 Larry Archer this is a big problem

            Show
            nightwolfzor Night Wolf added a comment - +1 Larry Archer this is a big problem
            Hide
            jonwolfe jon wolfe added a comment -

            +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)
            ...
            
            Show
            jonwolfe jon wolfe added a comment - +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) ...
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            cs94njw Nicholas Wright added a comment -

            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.

            Show
            cs94njw Nicholas Wright added a comment - 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.
            Hide
            cs94njw Nicholas Wright added a comment -

            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.

             

             

            Show
            cs94njw Nicholas Wright added a comment - 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.    

              People

              • Assignee:
                wolfs Stefan Wolf
                Reporter:
                evilchili evilchili
              • Votes:
                5 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated: