CODEWITHSUNDEEP
jenkinsgroovyjenkins-pipeline
fluminis
fluminis

Reputation: 4109

How to store the previous parameters values in a Jenkins Pipeline?

In jenkins 2.73.1, I have a pipeline job written in groovy with two String parameters: ReleaseVersion and NextDevelopmentVersion.

I want to simplify the use of the job by storing / updating the current job parameters values at the end of the script so that they will be the next default values for the next build.

Example:
User enter the following values for the current build:

ReleaseVersion = 1.2.3
NextDevelopmentVersion = 1.2.4-SNAPSHOT

I want to update the job default value so that the next build will display

ReleaseVersion = 1.2.4
NextDevelopmentVersion = 1.2.5-SNAPSHOT

Is that possible? How to do that in groovy?

I found this question how to store last value of parameter in parameterized job as a default value for? but could not make it work.

Upvotes: 3

Views: 6677

Answers (4)

t0r0X
t0r0X

Reputation: 4812

In a Jenkins declarative pipeline you could implement it like this, without any additional plugins:


///////////////////////////////////////////////////////////////
String incrementPatchVersion(String version, String defaultVersion) {
    String pattern = /^(\d{1,3})\.(\d{1,3})\.(\d{1,3})(-SNAPSHOT)?$/
    if (!version || !(version =~ pattern)) {
        return defaultVersion
    }

    def (_, major, minor, patch, snapshot) = (version =~ pattern)[0]
    if (!patch?.isInteger()) {
        return defaultVersion
    }

    int patchNew = (patch as Integer) + 1
    return  "${major}.${minor}.${patchNew}${snapshot ?: ''}"
}

///////////////////////////////////////////////////////////////
pipeline {
    agent { label any }

    parameters {
        string(name: 'ReleaseVersion',
              defaultValue: incrementPatchVersion(params.ReleaseVersion, '1.0.0'),
              description: 'Build version')
        string(name: 'NextDevelopmentVersion',
              defaultValue: incrementPatchVersion(params.NextDevelopmentVersion, '1.0.1-SNAPSHOT'),
              description: 'Next build version')
    }

    stages {
        stage('Initialize') {
            steps {
                echo "ReleaseVersion:         ${env.ReleaseVersion}"
                echo "NextDevelopmentVersion: ${env.NextDevelopmentVersion}"

                script {
                    // Skip unsafe steps/calls !!!
                    if (params.ReleaseVersion && params.NextDevelopmentVersion) {
                        echo "... legal values here => can process ..."
                    }
                }
            }
        }
    }

    post {
        always {
            script {
                currentBuild.description = "${params.ReleaseVersion} / ${params.NextDevelopmentVersion}"
            }
        }
    }
}

Note that the first build of the pipeline is always with null parameter values, as the pipeline definition was not yet read, so you have to guard relevant code blocks against null values, because there no build parameters without a first successful build.

Upvotes: 0

conan conan
conan conan

Reputation: 49

use parameters as follows:

node {
    properties([parameters([string(defaultValue: this.abc, description: '', name: 'abc', trim: false)])])
    echo params.abc
}

Upvotes: 0

Lee Meador
Lee Meador

Reputation: 12985

The question is 9 months old and Jenkins pipeline features have changed a lot during that time. All I can say is that this seems to work as of today in Jenkins 2.73.

In the Jenkinsfile you can have a section like this to set up some build parameters:

properties properties: [
    parameters([
            string(defaultValue: env.VERSION, description: 'Version to deploy', name: 'VERSION'),
    ])
]

When someone clicks "build now" for this job, enters the version value and clicks "build", the default values from the job configuration will set up the environment variable VERSION for use as the Jenkinsfile runs.

So the value the user typed in will be set back into the job configuration as the new default. This makes no difference on the current run but it will apply on the next run.

When the next run happens as the user clicks "build now" again, that value will appear as the default.

I'm pretty sure, as complicated as this is, that it might not always work this way. But the down side is pretty limited in that all that can happen is that the user has to type the correct new version number into the box before clicking the "build" button.

Upvotes: 0

Andrew Gray
Andrew Gray

Reputation: 3669

Pass those values as parameters to your job and read in the variables in your pipeline code.

Then use the Rebuild plugin which will allow you to rerun the job with the parameters of a previous build. No configuration necessary.

Upvotes: 2

Related Questions