Jenkins Pipeline同任务跨构建变量共享及阶段执行优先级控制需求

Alright, let's break down how to solve this Jenkins Pipeline challenge—sharing variables across different builds of the same job and using those variables to control stage execution with priority-based logic. I've got a few practical approaches for you:

First, you need a way to persist or access variables from previous builds. Here are the most reliable methods:

• Access Historical Build Environment Variables
  Jenkins lets you pull variables directly from past builds using the currentBuild object. This works great if you just need to carry over variables from the immediate prior build:

  // Grab variables from the previous build (handle first-build edge case)
  def previousPriority = currentBuild.previousBuild ? currentBuild.previousBuild.getEnvironment().get('BUILD_PRIORITY') : 'medium'
  def sharedConfig = currentBuild.previousBuild ? currentBuild.previousBuild.getEnvironment().get('SHARED_CONFIG') : 'default'
  

  Just make sure you export the variables in earlier builds using env.VAR_NAME = value so they're stored in the build's environment.

• Persistent File Storage
  For longer-term persistence (or if you need to share across multiple builds), write variables to a file outside the job's workspace (since workspaces can be cleaned up). Use Jenkins' built-in file utilities:

  // Path to a persistent file on the Jenkins server (ensure Jenkins has read/write access)
  def persistFile = '/var/jenkins_shared/my_job_vars.properties'
  
  // Write variables to the file
  writeFile file: persistFile, text: """BUILD_PRIORITY=${currentPriority}
  SHARED_CONFIG=${sharedConfig}"""
  
  // Read variables back in future builds
  def storedVars = readProperties file: persistFile
  def savedPriority = storedVars['BUILD_PRIORITY'] ?: 'low'
  

  Add a lock block if multiple builds might access this file concurrently to avoid race conditions:

  lock(resource: 'my_job_shared_vars') {
      // Read/write operations here
  }
  

• Global System Properties
  If variables need to be shared across all jobs (not just this one), use system properties—but be cautious, since this affects the entire Jenkins instance:

  // Set a global property
  System.setProperty('myJob.buildPriority', 'high')
  // Retrieve it
  def globalPriority = System.getProperty('myJob.buildPriority') ?: 'medium'
  

Once you have your shared variables, you can use them to conditionally run stages or adjust execution order.

Conditionally Skip Stages #

Use the when directive in declarative pipelines to skip stages based on priority:

pipeline {
    agent any
    environment {
        // Fetch shared priority using a helper function
        BUILD_PRIORITY = getSharedPriority()
    }
    stages {
        stage('Build') {
            steps {
                echo "Starting build with priority: ${BUILD_PRIORITY}"
                // Your build steps here
            }
        }
        stage('Full Test Suite') {
            when {
                expression { env.BUILD_PRIORITY == 'high' }
            }
            steps {
                echo "Running full tests for high-priority build"
                // Full test steps
            }
        }
        stage('Smoke Tests Only') {
            when {
                expression { env.BUILD_PRIORITY != 'high' }
            }
            steps {
                echo "Running minimal smoke tests for lower-priority build"
                // Smoke test steps
            }
        }
        stage('Deploy to Production') {
            when {
                expression { env.BUILD_PRIORITY == 'high' }
            }
            steps {
                echo "Deploying directly to production"
                // Production deploy steps
            }
        }
        stage('Deploy to Staging') {
            when {
                expression { env.BUILD_PRIORITY in ['medium', 'low'] }
            }
            steps {
                echo "Deploying to staging for validation"
                // Staging deploy steps
            }
        }
    }
}

// Helper function to fetch and calculate priority
def getSharedPriority() {
    // Check if previous build exists and has a priority
    if (currentBuild.previousBuild) {
        def prevPriority = currentBuild.previousBuild.getEnvironment().get('BUILD_PRIORITY')
        // Override to high if this build was manually triggered
        if (currentBuild.buildCauses.any { it.shortDescription.contains('Started by user') }) {
            return 'high'
        }
        return prevPriority ?: 'medium'
    }
    // Default priority for first build
    return 'medium'
}

Dynamic Stage Order #

If you need to reorder stages based on priority, use a scripted pipeline to dynamically generate stages:

node {
    def buildPriority = getSharedPriority()
    def stages = []

    // Always run the build stage first
    stages << [name: 'Build', steps: { echo 'Executing build steps...' }]

    // Add priority-specific stages
    if (buildPriority == 'high') {
        stages << [name: 'Security Scan', steps: { echo 'Running vulnerability scan...' }]
        stages << [name: 'Full Integration Tests', steps: { echo 'Running integration tests...' }]
    } else {
        stages << [name: 'Unit Tests', steps: { echo 'Running unit tests only...' }]
    }

    // Add deploy stage in the right position
    stages << buildPriority == 'high' ? 
        [name: 'Deploy to Prod', steps: { echo 'Deploying to production...' }] :
        [name: 'Deploy to Staging', steps: { echo 'Deploying to staging...' }]

    // Execute all generated stages
    stages.each { stageDef ->
        stage(stageDef.name) {
            stageDef.steps()
        }
    }
}

• Handle edge cases: Always set default values for variables (like when there's no previous build) to avoid pipeline failures.
• Secure sensitive variables: Don't store secrets in plaintext files—use Jenkins Credentials instead.
• Avoid race conditions: Use the lock directive when accessing shared files to prevent concurrent builds from overwriting data.

内容的提问来源于stack exchange，提问作者Siddhant Mishra