Jenkins: set a parameter defaultValue dynamically

Question

I'm trying to set up a multibranch pipeline configuration where the "Deploy" boolean checkbox is defaulted to true on non-production branches, and false on the production build.

pipeline {
  parameters{
    booleanParam(defaultValue: true, description: 'Do deploy after build', name: 'DEPLOY')

Is there some method to conditionally set defaultValue=false when $BRANCH_NAME == "production"?

Are you asking how to make the default value of one parameter dependent upon the input value of another parameter? — Matthew Schuchard, Feb 17 '20 at 20:46
Well, the defaultValue dependent on the $BRANCH_NAME variable, which is derived in Jenkins from the git branch. Or anything that would accomplish the goal of having a single Jenkinsfile duplicated across all the branches, but have the deploy job behave differently for production. I'd like the build to force the developers to check the deploy option to do the deploy instead of it being an automated process. — Cal, Feb 17 '20 at 21:04
In that case your variable is part of the environment, and therefore also the `env` map. Since you would be conditionally setting a boolean based on a string, and not just merely performing variable manipulation and interpolation, I foresee this requiring the full `parameters` class. Alternatively, you could set a global variable at the beginning of the pipeline, which would be much easier, although not as clean. — Matthew Schuchard, Feb 17 '20 at 21:46
I'm kind of struggling with the groovy syntax, and also what directives are allowed in which block of the Jenkinsfile. Can you mock up something that would be an example of that? — Cal, Feb 17 '20 at 22:20

score 15 · Answer 1 · answered Feb 18 '20 at 19:05

15

I think I might have answered my own question through a bunch of experimentation. This seems crazy simple, but my test between two branches shows the Deploy parameter is properly defaulted on/off depending on the $BRANCH_NAME

def defaultDeploy = true
if ( BRANCH_NAME == "production" )
{
  defaultDeploy = false
}
pipeline {
  parameters{
    booleanParam(defaultValue: defaultDeploy, 
      description: 'Do deploy after build', name: 'DEPLOY')

answered Feb 18 '20 at 19:05

Cal

411
1
3
11

1

If I had a penny for every time I used `def` statements and other logic above the `pipeline` start... – Nick Jones May 28 '22 at 19:06

ceztko · Answer 2 · 2020-03-24T10:21:49.627

Answering the question of the poster in a more generic way, the parameters default values can also be set dynamically injecting properties with EnvInject plugin. Also Extended Choice Parameter plugin is needed to run the example. Create a declarative pipeline project with the following content:

pipeline {
    agent any
    parameters {
        extendedChoice(
            name: 'ArchitecturesCh',
            defaultValue: "${env.BUILD_ARCHS}",
            multiSelectDelimiter: ',',
            type: 'PT_CHECKBOX',
            value: 'linux-x86_64,android-x86_64,android-arm,android-arm64,ios-arm64,Win32,Win64'
        )
        string(name: 'ArchitecturesStr', defaultValue: "${env.BUILD_ARCHS}", description: "")
    }
    stages {
        stage('Test') {
            steps {
                echo params.ArchitecturesCh
                echo params.ArchitecturesStr
                echo "${env.BUILD_ARCHS}"
            }
        }
    }
}

Then prepare an environment with the EnvInject plugin. NOTE: Be careful not to clash with other environment variables. In my case I lost much time thinking the method was not working because an ARCHITECTURES variable is set somewhere else. In the same pipeline project GUI:

Save and build the pipeline, refresh the page. The default parameters will be available in the following build.

score 1 · Answer 3 · answered Feb 17 '20 at 21:15

1

In your question, it's a bit unclear whether BRANCH_NAME refers to an environment variable (as in env.BRANCH_NAME) or to another parameter (as in params.BRANCH_NAME).

If former, then there's some environment variables, meaning that there's an environment, and so a node must have been allocated with its environment set. To allocate a node, the pipeline needs to start running. To start running, the user needs to select the parameters to run the pipeline. So it's a chicken-and-egg problem: you can't have environment variable before running pipelines, and you need to determine the parameters before running the pipeline.

If latter, and you are thinking of a case where, maybe, there's a String parameter that goes by the name of BRANCH_NAME, and a Boolean parameter that goes by the name of DEPLOY, and on the parameters page the checkbox DEPLOY is unchecked when you type maste into BRANCH_NAME, but once you press the r it magically becomes checked ... then it could be done — with a lot of pain — by using the Active Choice plugin.

Finally, if what you want is to prevent any deploying from the master branch, you may check for both the parameter and the branch name before deploying, and refuse to deploy if the parameter is false or if the branch is master.

answered Feb 17 '20 at 21:15

MaratC

6,418
2
20
27

To answer your question, I do have a separate parameter for overriding the $BRANCH_NAME, but this is only for doing feature deploys, which would be fairly rare. My parameter for that looks like this: `string(name: 'GIT_BRANCH', defaultValue: "${BRANCH_NAME}", description: 'the Branch/SHA1/Tag to build')` But the `$BRANCH_NAME` is populated by Jenkins by the multipipeline setup (I think) So, in general are you saying that it's not worth the trouble, and find another method for a paranoia check in the deployment scripts of the app? – Cal Feb 17 '20 at 21:40
So, feature (non-master) deploys are rare, and for master you want an extra confirmation? I would go with the params as in your original post, but `false` as a default. – MaratC Feb 18 '20 at 04:19
Ideally, for master I'd like them to do the "poll SCM" option so that on a git push, it automatically builds & deploys master to the development environment. But production, I would not want it to automatically deploy and be a manual click. – Cal Feb 18 '20 at 14:19
We do this by analyzing the build reason, so it's different for a person or scheduler or webhook/commit. Once you know the reason, you can write logic around that. – MaratC Feb 18 '20 at 15:37
Great explanation, thanks! Especially the part with a 'chicken & egg' problem about env. variables. – Foxy Fox Oct 19 '22 at 10:31

Jenkins: set a parameter defaultValue dynamically

3 Answers3