如何在声明性管道中等待用户输入而不会阻止重量级执行程序 [英] How to wait for user input in a Declarative Pipeline without blocking a heavyweight executor

问题描述

我正在将现有的构建管道重建为詹金斯声明性管道(多分支管道)，并且在处理构建传播方面遇到问题.

I'm rebuilding an existing build pipeline as a jenkins declarative pipeline (multi-branch-pipeline) and have a problem handling build propagation.

打包并存储所有相关文件后，管道应等待用户输入触发部署.

After packaging and stashing all relevant files the pipeline is supposed to wait for user input to trigger deployment.

如果我只是添加一个输入步骤，则当前构建节点被阻止.由于该执行程序非常繁重，因此我想将此步骤转移到更轻巧的机器上.

If i just add an input step the current build-node is blocked. As this executor is pretty heavy i would like to move this step to a more lightweight machine.

最初，我以脚本管道的形式完成了该工作，并创建了两个不同的node('label')块.我有办法对声明性语法做类似的事情吗?

Initially i did the job as a scripted pipeline and just created two different node('label') blocks. is there a way for me to do something similar with the declarative syntax?

node('spine') { 
    stage('builder') {
        sh 'mvn clean compile'
        stash name: 'artifact', includes: 'target/*.war'
    }
}
node('lightweight') {
    stage('wait') {
        timeout(time:5, unit:'DAYS') {
            input message:'Approve deployment?'
        }
    }
    // add deployment stages
}

我已经尝试了几件事:

在顶级配置代理，并在传播步骤中添加其他代理配置，但是由于顶级定义的构建节点未停止，因此我有两个执行程序受阻.

configuring the agent on the top-level and adding an additional agent config to the propagation step, but then i have two executors blocking as the top-level defined build-node is not stopped.

在顶级上设置agent none并按步骤配置代理.则git checkout在第一个节点上不存在.

Setting agent none on top-level and configuring the agents per step. then the git checkout is not present on the first node.

编辑1

我根据您的建议重新配置了管道，目前看起来像这样:

i reconfigured my pipeline following you advice, it currently looks like this:

pipeline {
agent none
tools {
    maven 'M3'
}
stages {
    stage('Build') {
        agent { label 'spine' }
        steps {
            checkout scm // needed, otherwise the workspace on the first step is empty
            sh "mvn clean compile"
        }
    }
    stage('Test') {
        agent { label 'spine' }
        steps {
            sh "mvn verify" // fails because the workspace is empty aggain
            junit '**/target/surefire-reports/TEST-*.xml'
        }
    }
}
}

此构建将失败，因为工作空间没有在同一执行程序上运行，因此工作空间不会在步骤之间转移.

this build will fail because the workspace does not carry over between steps as they dont run on the same executor.

编辑2

显然，有时这些步骤是在同一执行程序上运行的，有时却不在同一执行程序上运行. (我们根据需要在mesos/dcos集群上生成构建从属，因此在中间构建过程中更改执行程序将是一个问题)

apparently sometimes the steps run on the same executor and sometimes don't. (we spawn build slaves on our mesos/dcos cluster on demand, so changing the executor mid build would be a problem)

我希望jenkins可以与当前执行程序一起运行，只要代理定义中的标签不变即可.

I expected jenkins to just run with the current executor as long as the label in the agent definition does not change.

推荐答案

请参见最佳做法7 :不要:在节点块中使用输入.在声明性管道中，节点选择是通过agent指令完成的.

See best practice 7: Don’t: Use input within a node block. In a declarative pipeline, the node selection is done through the agent directive.

文档此处描述了如何定义none ，然后使用阶段级agent指令在所需节点上运行阶段.我也尝试了相反的方法(在某个节点上定义一个全局代理，然后在阶段级为输入定义none)，但这不起作用.如果管道分配了一个从站，则您不能在一个或多个特定阶段释放该从站.

The documentation here describes how you can define none for the pipline and then use a stage-level agent directive to run the stages on the required nodes. I tried the opposite too (define a global agent on some node and then define none on stage-level for the input), but that doesn't work. If the pipeline allocated a slave, you can't release the slave for one or more specific stages.

这是我们的管道的结构:

pipeline {
  agent none
  stages {
    stage('Build') {
      agent { label 'yona' }
      steps {
        ...
      }
    }
    stage('Decide tag on Docker Hub') {
      agent none
      steps {
        script {
          env.TAG_ON_DOCKER_HUB = input message: 'User input required',
              parameters: [choice(name: 'Tag on Docker Hub', choices: 'no\nyes', description: 'Choose "yes" if you want to deploy this build')]
        }
      }
    }
    stage('Tag on Docker Hub') {
      agent { label 'yona' }
      when {
        environment name: 'TAG_ON_DOCKER_HUB', value: 'yes'
      }
      steps {
        ...
      }
    }
  }
}

通常，构建阶段在标有"yona"的构建从属服务器上执行，但输入阶段在主服务器上运行.

Generally, the build stages execute on a build slave labeled "yona", but the input stage runs on the master.

这篇关于如何在声明性管道中等待用户输入而不会阻止重量级执行程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！