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.

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.

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.

I have the same problem as in the previous comment.

How can I delete cached values?

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.

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.

+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! )

Adding my request for this as well.  It is impossible to reuse a pipeline with different configurations (defined in the UI which is most accessible to users) with cron or scm triggered jobs that rely on the default job parameters to configure it.  It works up until the point someone does a manual run with parameter overrides, in which case those parameters become the new defaults and this has caused us grief more than once.  There should be a distinction between changing parameters while editing the job (default values) and setting parameters when running a job (default overrides), which, by the way, is how it works with freestyle jobs.