Jenkins Pipeline 条件阶段成功，但 Jenkins 显示构建失败答案

【问题标题】：Jenkins Pipeline conditional stage succeeds but Jenkins shows build as failedJenkins Pipeline 条件阶段成功，但 Jenkins 显示构建失败
【发布时间】：2017-07-11 20:47:19
【问题描述】：

Jenkins 版本 = 2.19 Jenkins Multibranch Pipeline 插件版本 = 2.92

我有一个 Jenkinsfile，其中包含基于分支的几个条件阶段。

为了简洁起见，这是我的 Jenkinsfile 的修改版本：

node {
    stage('Checkout') {
        checkout scm
    }

    stage('Clean Verify') {
        sh 'mvn clean verify'
    }

    if (env.BRANCH_NAME == "develop") {
        stage('Docker') {
            sh 'mvn docker:build -DpushImage'
        }
    }
}

我正在使用多分支管道插件。

它成功检测并构建了我所有的分支。

我遇到的问题是所有构建都报告为失败，即使我将每个阶段都悬停它报告“成功”。

我附上了一张图片，显示了一个功能分支，其中我想运行的两个阶段已经运行并成功完成，但您可以看到构建实际上报告为失败。

对于开发分支，我也得到完全相同的结果 - 它成功执行 Docker 阶段，但构建报告失败。

我的期望是每个分支都将报告成功，因为该分支运行的阶段都通过了。

编辑 1

这是构建日志的结尾（我希望这已经足够了，因为我不想挑选所有私人信息，但如果需要请告诉我）

[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 30.459 s
[INFO] Finished at: 2017-02-21T15:13:02+11:00
[INFO] Final Memory: 84M/769M
[INFO] ------------------------------------------------------------------------
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] sh
Required context class hudson.FilePath is missing
Perhaps you forgot to surround the code with a step that provides this, such as: node
[Pipeline] End of Pipeline
org.jenkinsci.plugins.workflow.steps.MissingContextVariableException: Required context class hudson.FilePath is missing
    at org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:253)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:179)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:126)
at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)
at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:151)
at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:21)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:115)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:103)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16)
at WorkflowScript.run(WorkflowScript:93)
at ___cps.transform___(Native Method)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.GeneratedMethodAccessor501.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:58)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:163)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:63)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Finished: FAILURE

【问题讨论】：

您能告诉我们构建日志中的内容吗？

标签： jenkins jenkins-pipeline

【解决方案1】：

所以在仔细查看日志文件后，它帮助我找到了问题所在。

值得注意的是，单击构建阶段查看日志是让我大吃一惊的——这就是我一直在做的事情。当我真正进入完整的控制台日志输出时，我看到了以下错误：

Required context class hudson.FilePath is missing
Perhaps you forgot to surround the code with a step that provides this, such as: node

在我拥有的节点 {} 部分下方，我有一个部署声明：

def branch = readFile('branch').trim()
if (branch == master) {
    ...
}

问题在于 readFile 语句是在节点之外定义的。

答案是将 readFile 语句放在 node {} 部分中。

【讨论】：

必须在节点上下文中执行这一事实是一个非常重要的细节。这就是让我绊倒的原因。
但是看原帖，好像代码在node {}块里面？

【解决方案2】：

我知道这已经过时了，但我在声明性管道中遇到了类似的问题，并在这里登陆。事实证明，我试图使用sh 在pipeline 块中设置environment 变量，但我的主要agent 是none，即：

pipeline {
    agent none
    environment {
        VERSION = sh(returnStdout: true, script: 'git describe --tags')
    }
}

这导致了同样的错误Required context class hudson.FilePath is missing。将其移动到带有agent 的stage 可以正常工作。

【讨论】：

您可以通过以下方式定义全局变量：在文件顶部（pipeline 之前）创建一个变量，如下所示：def my_variable。然后你可以在你的第一个构建步骤中实例化这个全局变量：script { my_variable = sh(script: "do_stuff", returnStdout: true).trim() }。因此，您现在可以在其他阶段重用该变量，因为它现在是您的Jenkinsfile 中的全局变量。希望这会有所帮助。
当我在一个环境块中使用 credentials("credential-id") 时遇到了同样的问题，该环境块的代理标签为 none，在我的例子中是块阶段之前的第一个块。

【解决方案3】：

我对错误Required context class hudson.FilePath is missing Perhaps you forgot to surround the code with a step that provides this, such as: node的解决方案

是：

#!/usr/bin/env groovy
import hudson.model.*

node('master') {
    sh("your shell script")   
}

【讨论】：

【解决方案4】：

在我的情况下，它突然停止工作，出现错误：

Required context class hudson.FilePath is missing
Perhaps you forgot to surround the code with a step that provides this, such as: node

原因是节点只是关闭了。必须重新启动它并重新启动它的代理（它是奴隶）。

【讨论】：

感谢您，我们每 100 个左右的工作中就有一次，很难弄清楚发生了什么，但我认为您的评论可能会给我们一个线索。谢谢。
我的 ec2 从节点时间与主节点不同步，重新启动并且管道正常工作。这个答案给了我一个提示。谢谢。

【解决方案5】：

sh 命令最后没有用引号结束。

【讨论】：

感谢您指出这一点。这只是我的 SO 帖子中的一个错字，虽然不在 Jenkinsfile 本身中

【解决方案6】：

如果您的分支被删除，则可能会发生此错误，并会显示以下错误：

引起：org.codehaus.groovy.runtime.InvokerInvocationException： org.jenkinsci.plugins.workflow.steps.MissingContextVariableException：缺少所需的上下文类 hudson.FilePath 14:25:07 也许您忘记用提供此功能的步骤包围代码，例如如：节点

THEN 最后还会说：

错误：找不到要构建的任何修订。验证存储库和此作业的分支配置。

在我们的例子中，我们有时会设置一个作业来使用仍在 PR 中的分支，并且一旦 PR 被合并，该分支就会被自动删除（例如 https://stackoverflow.com/a/57328204/292408）。

如果这是您的情况，请恢复作业中的分支并且它应该再次工作。如果您看到此错误不一致，那么这可能是您的问题。

【讨论】：

发生在一个可怕的失控构建情况下，有人将每个分支配置为构建另一个分支，而当队列中的内容旨在针对未提交的提交运行时，人们仍在重新定位和重新推送不存在了...非常感谢您留下此评论>。
哇！很高兴它对您有所帮助，谢谢！

【解决方案7】：

我遇到了这个错误：

执行总是后置条件时出错：org.jenkinsci.plugins.workflow.steps.MissingContextVariableException：缺少必需的上下文类 hudson.FilePath
也许您忘记在代码中加上提供此功能的步骤，例如：node

这是由模糊插值引起的：

environment {
    FILE = "some-$BRANCH.yml"
}

这种情况下的正确表达是：

"some-${BRANCH}.yml"

【讨论】：