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

External way to set default parameter values for a pipeline job

    XMLWordPrintable

Details

    Description

      As a user, I would like to reuse a Jenkinsfile across different Jenkins installations and being capable of setting parameters inside a Jenkinsfile, with default values that are loaded from some other source.

      For example:

      I have a project that is built on two different Jenkins installations that are running on different environments. For security reasons the environments needs to be separate. Each environment has some differences that I need to set in the parameters, in order to be able to run the job. At the moment I am obligated to use "ifs" based on the env.JOB_NAME in order to change each defaultValue for every parameter. 

      Not only this, but I also need to use a cron trigger for this pipeline, which forcibly uses the default values to run it.

      I've tried many hacks to make the defaults to be loaded from some other place, but they don't play nicely with the way Jenkins constructs the "Build with Parameters" form. The Jenkinsfile is not pre-executed neither pre-loaded in order to construct this form, so even if I find a way to dynamically set the defaultValue for every parameter, this value will not be kept.

      So, I believe Jenkins should have one of the following solutions:

      • A way to preload the Jenkinsfile from the source repository, without having to run through the steps, including running part of the Jenkinsfile to be able to dynamically set default values for the parameters (ex.: getting values from env and using as defaultValue in the preload).
      • A way to set the defaults that is separate from the Jenkinsfile - could be directly in the job configuration

      Attachments

        Activity

          svanoort Sam Van Oort added a comment -

          hgfxng This is a completely reasonable enhancement but please reserve Critical priority for features that are needed to use Pipelines in a standard, common way. For bugs, Critical would be something that brings Jenkins down completely or renders core functionality unusable (i.e. a regression meaning that no Pipelines run, or for an SCM, you can't check out code ever), so keep that in mind. Thanks!

          This is a pretty specialized usage you're describing, so I'm adjusting priority accordingly... but also voting for the issue myself because in my Jenkins usage I need default parameter handling and have been annoyed by the need for code hacks to work around it.

          svanoort Sam Van Oort added a comment - hgfxng This is a completely reasonable enhancement but please reserve Critical priority for features that are needed to use Pipelines in a standard, common way. For bugs, Critical would be something that brings Jenkins down completely or renders core functionality unusable (i.e. a regression meaning that no Pipelines run, or for an SCM, you can't check out code ever), so keep that in mind. Thanks! This is a pretty specialized usage you're describing, so I'm adjusting priority accordingly... but also voting for the issue myself because in my Jenkins usage I need default parameter handling and have been annoyed by the need for code hacks to work around it.
          steph Steph Gosling added a comment -

          Another +1 for this feature, my use case is different but I'd say the usage isn't that specialised: I have a simple build CI/CD pipeline for a F/OSS project however the artifact it builds needs to be uploaded somewhere: for me this is a cloud object store. I do not want to leak object store buckets or paths that are specific to my companies' implementation of this project. I'd like to do it all within the same pipeline but as I can't I'm looking at the workflow plugin instead, simply to do the upload.

          steph Steph Gosling added a comment - Another +1 for this feature, my use case is different but I'd say the usage isn't that specialised: I have a simple build CI/CD pipeline for a F/OSS project however the artifact it builds needs to be uploaded somewhere: for me this is a cloud object store. I do not want to leak object store buckets or paths that are specific to my companies' implementation of this project. I'd like to do it all within the same pipeline but as I can't I'm looking at the workflow plugin instead, simply to do the upload.
          bentzy Bentzy Sagiv added a comment - - edited

          Thats what I do:

          at jenkinsfile.pipeline.properties:

           distribution_property=testing tag_property=RanByJenkins_FromPropertiesFile

          at Jenkinsfile:

          node {
            def props = readProperties file: "<YOUR_PATH>/jenkinsfile.pipeline.properties"
          
            def distribution= props['distribution_property'] 
          
            def tag= props['tag_property']
            properties([
              parameters([ 
               string(name: 'distribution', defaultValue: "$distribution", description: 'apt distribution'),
               string(name: 'tag', defaultValue: "$tag", description: 'just a tag')
             ])
           ])
           echo "distribution: $distribution"
           echo "tag: $tag"
           ...

          Default values are took from properties file.
          Default values can be overriden at UI.
          Values at UI are cached from last run.
          To restore defaults (from properties file) for next run just delete cached values.

           

          bentzy Bentzy Sagiv added a comment - - edited Thats what I do: at jenkinsfile.pipeline.properties:  distribution_property=testing tag_property=RanByJenkins_FromPropertiesFile at Jenkinsfile: node { def props = readProperties file: "<YOUR_PATH>/jenkinsfile.pipeline.properties" def distribution= props[ 'distribution_property' ] def tag= props[ 'tag_property' ] properties([ parameters([ string(name: 'distribution' , defaultValue: "$distribution" , description: 'apt distribution' ), string(name: 'tag' , defaultValue: "$tag" , description: 'just a tag' ) ]) ]) echo "distribution: $distribution" echo "tag: $tag" ... Default values are took from properties file. Default values can be overriden at UI. Values at UI are cached from last run. To restore defaults (from properties file) for next run just delete cached values.  
          katerynaskok Kateryna Skok added a comment -

          I have the same problem as in the previous comment.

          How can I delete cached values?

          katerynaskok Kateryna Skok added a comment - I have the same problem as in the previous comment. How can I delete cached values?
          ceztko Francesco Pretto added a comment - - edited

          This issue mentions EnvInject and pipeline in the tags so I expect the poster wants to dynamically modify the default value of the parameters in a pipeline project, possibly stored as a Jenkinsfile in CSM, directly in the Jenkins project where it is configured. My tests show that is already possible in a similar way the user bentzy is performing and precisely creating an environment with the EnvInject plugin. Try the example pipeline and setup described in this Stack Overflow post .

          ceztko Francesco Pretto added a comment - - edited This issue mentions EnvInject and pipeline in the tags so I expect the poster wants to dynamically modify the default value of the parameters in a pipeline project, possibly stored as a Jenkinsfile in CSM, directly in the Jenkins project where it is configured. My tests show that is already possible in a similar way the user bentzy is performing and precisely creating an environment with the EnvInject plugin. Try the example pipeline and setup described in this Stack Overflow post .

          I'd like to give a +1 to that feature as well. In case of my client we have two Jenkins instances: test and production one, each one with its own Jenkinsfile which are almost the same, except for the default parameter values, which cannot be specified in the Jenkins job configuration itself. We have to rely on them, since our build are executed by webhooks. Any modification attempt in the GUI is overridden by the value from the used Jenkinsfile. It makes it necessary to have two almost exactly the same Jenkinsfiles, save for the default values of the parameters, or doing some properties magic like the one Bentzy posted, resulting in a messy Jenkinsfile.

          It would be great if the GUI-configured parameters had a higher priority than the ones from the used Jenkinsfile so that those can be easily overridden on per-job basis.

          konpon96 Konrad Ponichtera added a comment - I'd like to give a +1 to that feature as well. In case of my client we have two Jenkins instances: test and production one, each one with its own Jenkinsfile which are almost the same, except for the default parameter values, which cannot be specified in the Jenkins job configuration itself. We have to rely on them, since our build are executed by webhooks. Any modification attempt in the GUI is overridden by the value from the used Jenkinsfile. It makes it necessary to have two almost exactly the same Jenkinsfiles, save for the default values of the parameters, or doing some properties magic like the one Bentzy posted, resulting in a messy Jenkinsfile. It would be great if the GUI-configured parameters had a higher priority than the ones from the used Jenkinsfile so that those can be easily overridden on per-job basis.
          medianick Nick Jones added a comment -

          My situation is very similar, konpon96. I've got several dozen environments, so developed a parameterized Jenkins pipeline script (Jenkinsfile_Deploy) and have a correspondingly parameterized pipeline job in Jenkins that uses this script from SCM. But the job takes its parameter values from the pipeline script, and editing in the job configuration to override the script's defaults doesn't work; the next invocation of the job will reset the parameters to their script values. What I've had to do is use separate jobs (per environment) that call the parameterized job (via "Trigger/call builds on other projects" in Freestyle or "build" in Pipeline) and pass the desired parameter values – and this basically works – but this then means that the calling job has no connection to the repository in question, so can't poll for changes (and run/deploy only if there are any), display changelogs, etc.

          If the UI could retain its own copy of the parameter values that would override those in the pipeline script from SCM, I'd have everything I need.

          medianick Nick Jones added a comment - My situation is very similar, konpon96 . I've got several dozen environments, so developed a parameterized Jenkins pipeline script (Jenkinsfile_Deploy) and have a correspondingly parameterized pipeline job in Jenkins that uses this script from SCM. But the job takes its parameter values from the pipeline script, and editing in the job configuration to override the script's defaults doesn't work; the next invocation of the job will reset the parameters to their script values. What I've had to do is use separate jobs (per environment) that call the parameterized job (via "Trigger/call builds on other projects" in Freestyle or "build" in Pipeline) and pass the desired parameter values – and this basically works – but this then means that the calling job has no connection to the repository in question, so can't poll for changes (and run/deploy only if there are any), display changelogs, etc. If the UI could retain its own copy of the parameter values that would override those in the pipeline script from SCM, I'd have everything I need.
          joelleloving Joelle added a comment -

          +1

          For projects which need to repeatedly test against multiple environments, there should be a built-in way to configure parameters relative to the Jenkins job, not solely relative to the scm repository. As others have said, the simplest way of providing this would be storing default parameter settings in the job, and not overwriting them with the defaults from the Jenkinsfile.

          (But also appreciate bentzy 's workaround! )

          joelleloving Joelle added a comment - +1 For projects which need to repeatedly test against multiple environments, there should be a built-in way to configure parameters relative to the Jenkins job, not solely relative to the scm repository. As others have said, the simplest way of providing this would be storing default parameter settings in the job, and not overwriting them with the defaults from the Jenkinsfile. (But also appreciate bentzy 's workaround! )

          People

            Unassigned Unassigned
            hgfxng Herbert Fischer
            Votes:
            14 Vote for this issue
            Watchers:
            18 Start watching this issue

            Dates

              Created:
              Updated: