Avoiding hard-coded values in Jenkins - Commands & Configuration

Introduction

Hard-coded values in Jenkins pipelines make it hard to change settings later and reuse code. Avoiding them helps keep pipelines flexible and easier to maintain by using variables and parameters instead.

When you want to run the same pipeline with different branch names without changing the code.

When you need to deploy to different environments like staging or production using the same pipeline.

When you want to reuse the pipeline code across multiple projects with different settings.

When you want to update a server address or credentials without editing the pipeline script every time.

When you want to make your pipeline easier to understand by clearly naming important values.

Config File - Jenkinsfile

Jenkinsfile

pipeline {
  agent any
  parameters {
    string(name: 'BRANCH_NAME', defaultValue: 'main', description: 'Git branch to build')
    choice(name: 'ENVIRONMENT', choices: ['staging', 'production'], description: 'Deployment environment')
  }
  stages {
    stage('Checkout') {
      steps {
        echo "Checking out branch ${params.BRANCH_NAME}"
        git branch: "${params.BRANCH_NAME}", url: 'https://github.com/example/my-app.git'
      }
    }
    stage('Deploy') {
      steps {
        script {
          if (params.ENVIRONMENT == 'production') {
            echo 'Deploying to production server'
          } else {
            echo 'Deploying to staging server'
          }
        }
      }
    }
  }
}

This Jenkinsfile uses parameters to avoid hard-coded values.

The BRANCH_NAME parameter lets you choose which Git branch to build.

The ENVIRONMENT parameter lets you select the deployment target.

Using params.BRANCH_NAME and params.ENVIRONMENT in the script replaces fixed values with flexible inputs.

Commands

This command updates the Jenkins job with the new Jenkinsfile that uses parameters instead of hard-coded values.

Terminal

jenkins-jobs --conf jenkins.ini update Jenkinsfile

Expected Output

Job updated successfully

This command starts the Jenkins pipeline named 'my-pipeline' with parameters to build the 'feature-xyz' branch and deploy to the staging environment.

Terminal

jenkins-cli build my-pipeline -p BRANCH_NAME=feature-xyz -p ENVIRONMENT=staging

Expected Output

Started build #42

Building on master

[Pipeline] Start of Pipeline

[Pipeline] echo

Checking out branch feature-xyz

[Pipeline] git

Fetching changes from https://github.com/example/my-app.git

[Pipeline] echo

Deploying to staging server

[Pipeline] End of Pipeline

Finished: SUCCESS

→

-p BRANCH_NAME=feature-xyz - Sets the Git branch to build

→

-p ENVIRONMENT=staging - Sets the deployment environment

This command runs the same pipeline but builds the 'main' branch and deploys to production, showing how parameters replace hard-coded values.

Terminal

jenkins-cli build my-pipeline -p BRANCH_NAME=main -p ENVIRONMENT=production

Expected Output

Started build #43

Building on master

[Pipeline] Start of Pipeline

[Pipeline] echo

Checking out branch main

[Pipeline] git

Fetching changes from https://github.com/example/my-app.git

[Pipeline] echo

Deploying to production server

[Pipeline] End of Pipeline

Finished: SUCCESS

→

-p BRANCH_NAME=main - Sets the Git branch to build

→

-p ENVIRONMENT=production - Sets the deployment environment

Key Concept

If you remember nothing else from this pattern, remember: use parameters and variables in Jenkins pipelines to replace fixed values and make your pipeline flexible and reusable.

Common Mistakes

Hard-coding branch names or server addresses directly in the Jenkinsfile.

This makes the pipeline rigid and requires code changes for every small update or environment switch.

Use pipeline parameters and variables to pass these values when running the pipeline.

Forgetting to reference parameters with 'params.' prefix inside the Jenkinsfile.

The pipeline will not recognize the parameter values and may fail or use defaults unexpectedly.

Always access parameters using 'params.PARAMETER_NAME' syntax inside the pipeline script.

Not providing default values for parameters.

This can cause the pipeline to fail if no value is provided when starting the build.

Always set sensible default values for parameters to ensure smooth pipeline runs.

Summary

Use parameters in Jenkinsfiles to avoid hard-coded values and make pipelines flexible.

Pass values like branch names and environments as parameters when triggering builds.

Access parameters inside the pipeline script using the 'params' object.

Practice

1. Why should you avoid hard-coded values in Jenkins pipelines?

easy

A. Because Jenkins does not support hard-coded values

B. Because hard-coded values run faster

C. To reduce the number of pipeline steps

D. To make pipelines flexible and easier to maintain

Solution

1. Step 1: Understand pipeline flexibility

   Hard-coded values fix data in one place, making changes difficult and pipelines less reusable.

2. Step 2: Recognize benefits of environment variables

   Using environment variables allows easy updates and reuse without changing pipeline code.

3. Final Answer:

   To make pipelines flexible and easier to maintain -> Option D

4. Quick Check:

   Flexibility = Avoid hard-coded values [OK]

Hint: Remember: environment variables make pipelines flexible [OK]

Common Mistakes:

• Thinking hard-coded values improve speed
• Believing Jenkins disallows hard-coded values
• Confusing fewer steps with better practice

2. Which syntax correctly uses an environment variable MY_VAR in a Jenkins pipeline script?

easy

A. echo 'Value is $MY_VAR'

B. echo "Value is ${MY_VAR}"

C. echo "Value is %MY_VAR%"

D. echo "Value is MY_VAR"

Solution

1. Step 1: Identify correct variable syntax in Groovy

   Jenkins pipeline scripts use Groovy, where environment variables are accessed as ${VAR_NAME} inside strings.

2. Step 2: Compare options

   echo "Value is ${MY_VAR}" uses ${MY_VAR}, which is the correct Groovy syntax for environment variables in strings.

3. Final Answer:

   echo "Value is ${MY_VAR}" -> Option B

4. Quick Check:

   Groovy env var syntax = ${VAR} [OK]

Hint: Use ${VAR} to access env variables in Jenkins Groovy scripts [OK]

Common Mistakes:

• Using $VAR without braces in Groovy strings
• Using Windows-style %VAR% syntax
• Writing variable name as plain text

3. Given this Jenkins pipeline snippet:

environment {
  GREETING = 'Hello'
}

pipeline {
  agent any
  stages {
    stage('Print') {
      steps {
        echo "${GREETING}, World!"
      }
    }
  }
}

What will be the output when this pipeline runs?

medium

A. Hello, World!

B. ${GREETING}, World!

C. GREETING, World!

D. Error: GREETING not defined

Solution

1. Step 1: Understand environment block usage

   The environment block defines GREETING as 'Hello', making it available in the pipeline steps.

2. Step 2: Evaluate echo statement

   The echo uses "${GREETING}, World!" which substitutes GREETING with 'Hello'.

3. Final Answer:

   Hello, World! -> Option A

4. Quick Check:

   Env var substitution = Hello, World! [OK]

Hint: Environment vars replace ${VAR} in pipeline steps [OK]

Common Mistakes:

• Expecting literal ${GREETING} output
• Confusing variable scope outside environment block
• Assuming syntax error due to quotes

4. You have this Jenkins pipeline snippet:

environment {
  PASSWORD = credentials('my-secret')
}

steps {
  echo "Password is $PASSWORD"
}

What is the problem with this code?

medium

A. Echoing password directly exposes sensitive data

B. credentials() cannot be used inside environment block

C. Using $PASSWORD instead of ${PASSWORD} causes no substitution

D. Missing quotes around credentials ID

Solution

1. Step 1: Understand credentials usage

   Using credentials('my-secret') loads a secret securely into PASSWORD variable.

2. Step 2: Identify security risk

   Echoing the password directly prints sensitive data in logs, which is unsafe.

3. Final Answer:

   Echoing password directly exposes sensitive data -> Option A

4. Quick Check:

   Never print secrets in logs [OK]

Hint: Never echo secrets; use them securely [OK]

Common Mistakes:

• Thinking $PASSWORD syntax is wrong in Groovy
• Believing credentials() can't be in environment block
• Ignoring security risks of printing secrets

5. You want to avoid hard-coded URLs in your Jenkins pipeline. Which approach best achieves this while keeping the URL secret and reusable?

hard

A. Write the URL directly in the pipeline script as a string

B. Pass the URL as a command-line argument to Jenkins

C. Store the URL in Jenkins credentials and access it via environment variable

D. Use a global variable in the pipeline script with the URL

Solution

1. Step 1: Identify secure storage for sensitive data

   Jenkins credentials store secrets securely and allow reuse without exposing them in code.

2. Step 2: Use environment variables to access credentials

   Accessing credentials via environment variables avoids hard-coding and keeps pipelines flexible.

3. Final Answer:

   Store the URL in Jenkins credentials and access it via environment variable -> Option C

4. Quick Check:

   Secure reuse = credentials + env vars [OK]

Hint: Use Jenkins credentials for secret reusable values [OK]

Common Mistakes:

• Hard-coding secrets in scripts
• Passing secrets insecurely via command line
• Using global vars that expose secrets