Jenkins: What is a good way to store a variable between two job runs?

Question

I have a time-triggered job which needs to retrieve certain values stored in a previous run of this job.

Is there a way to store values between job runs in the Jenkins e

Answer 1

If you are using Pipelines and you're variable is of a simple type, you can use a parameter to store it between runs of the same job.

Using the properties step, you can configure parameters and their default values from within the pipeline. Once configured you can read them at the start of each run and save them (as default value) at the end. In the declarative pipeline it could look something like this:

pipeline {
  agent none
  options {
    skipDefaultCheckout true
  }
  stages {
    stage('Read Variable'){
      steps {
        script {
          try {
            variable = params.YOUR_VARIABLE
          }
          catch (Exception e) {
            echo("Could not read variable from parameters, assuming this is the first run of the pipeline. Exception: ${e}")
            variable = ""
          }
        }
      }

    }
    stage('Save Variable for next run'){
      steps {
        script {
          properties([
            parameters([
              string(defaultValue: "${variable}", description: 'Variable description', name: 'YOUR_VARIABLE', trim: true)
            ])
          ])
        }
      }
    }
  }

Answer 2

A few options:

• Store the data in the workspace. If the data isn't critical (i.e. it's ok to nuke it when the workspace is nuked) that should be fine. I only use this to cache expensive-to-compute data such as prebuilt library dependancies.
• Store the data in some fixed location in the filesystem. You'll make jenkins less self-contained and thus make migrations+backups more complex - but probably not by much; especially if you store the data in some custom user-subdirectory of jenkins. parallel builds will also be tricky, and distributed builds likely impossible. Jenkins has a userContent subdirectory you could use for this - that way the file is at least part of the jenkins install and thus more easily migrated or backed up. I do this for the (rather large) code coverage trend files for my builds.
• Store the data on a different machine (e.g. a database). This is more complicated to set up, but you're less dependant on the local machine's details, and it's probably easier to get distributed and parallel builds working. I've done this to maintain a live changelog.
• Store the data as a build artifact. This means looking at previous build's artifacts. It's safe and repeatable, and because Uri's are used to access such artifacts, OK for distributed builds too. However, you need to deal with failed builds (should you look back several versions? start from scratch?) and you'll be storing many copies, which is just fine if it's 1KB but less fine if it's 1GB. Another downside here is that you'll probably need to open up jenkin's security settings quite far to allow annonymous access to artifacts (since you're just downloading from a uri).

The appropriate solution will depend on your situation.

Answer 3

I would pass the variable from the first job to the second as a parameter in a parameterized build. See this question for more info on how to trigger a parameterized build from another build.