16

Sometimes, we want to create multiple jobs that use the same Jenkinsfile instead of a single one. This could happen for example because we want to maintain logs divided based on parameters, instead of having a single job on which look for the right log.

However, in this case, we can't use the parameter definition in the Jenkinsfile, because whatever default value we would define on the job instance would be overwritten by the following execution with whatever is defined in the Jenkinsfile (and this is also happening if we don't define a default value).

So, in this situation, the only way we figure out is to remove the parameter definition in the Jenkinsfile and define the parameters directly on the jobs, which is kind of not optimal.

I mean, I agree that this is the right behavior in most of the cases, as you don't want your parameter to be out of synch and not versioned, but is there a way to specify to Jenkins to skip the parameter reconfiguration or to override the default parameter written in the Jenkinsfile? Something that can be activated/deactivated job by job.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mikyjpeg
  • 1,179
  • 1
  • 13
  • 39
  • My suggestion would be to maintain different Jenkinsfile for different jobs, we usually follow that and if parameters are different job_names would be different and that is a good candidate to store the Jenkins configuration with a new Jenkinsfile – Dillip Kumar Behera Sep 02 '19 at 15:41
  • 2
    We would like to avoid that, because it would mean to increase maintenance for jobs that have the same exact logic. – Mikyjpeg Sep 03 '19 at 17:50
  • If you don't need to follow that, then keep the logic as shared-library and use the function call to create separate Jenkinsfile for separate jobs. – Dillip Kumar Behera Sep 04 '19 at 07:01
  • That wouldn't solve my problem: I would still have to duplicate Jenkinsfiles just to set the default values. Not much value compared with what we're already using. These jobs are going to be created and deleted automatically in a span of days/week, don't see any value on versioning the default values that are changing. – Mikyjpeg Sep 04 '19 at 15:59

1 Answers1

17

Had this problem myself, we solved it like this:

string(name: 'parameterName', defaultValue: params.parameterName ?:'your default value')

Now the default values defined through Jenkins job configuration will not be overridden.

finderAUT
  • 321
  • 3
  • 4
  • 1
    that's a simple and nice way to solve it! Never thought about it. thanks! – Mikyjpeg Jan 22 '20 at 16:03
  • This doesn't work for password types. `java.lang.ClassCastException: hudson.model.PasswordParameterDefinition.defaultValue expects class java.lang.String but received class hudson.util.Secret`. Not sure how to modify this to work. – RoboticRenaissance Sep 30 '20 at 12:29
  • 1
    Great solution! It took me a while to get this right because I had a space between `?` and `:`, but it worked after defining exactly as shown in the answer. – Fatore Jan 21 '21 at 11:15
  • This has a very unpleasant downside: Each job run will override defaults. – Andrey Ershov Sep 08 '21 at 17:40
  • You are a saint. Been pulling my hair out over this, I wanted staging, master branches to have separate settings but every time it polled the SCM it wiped all the parameter values. It only preserved them if you 'build with parameters' it. You deserve a medal <3 – MajorFailz Jul 06 '22 at 13:40
  • how can we add default value for choice parameter like you did for string – sasikala Sep 20 '22 at 09:12