shell - 在 Jenkins 中,Execute Shell 如何/何时将构建标记为失败?

我在寻找这个答案时发现的恐怖故事......

好的,我有一个 .sh 脚本,它几乎可以完成 Jenkins 应该做的所有事情:

  • 检查来自 SVN 的源代码
  • 构建项目
  • 部署项目
  • 自行清理

所以在 Jenkins 中,我只需要通过在 Execute Shell 命令中运行脚本来“构建”项目。 脚本已运行(源已下载,项目正在构建/部署),但随后它将构建标记为失败: 构建步骤“执行 shell”将构建标记为失败 即使脚本运行成功!我尝试关闭脚本:

  • 退出 0(仍将其标记为失败)
  • 退出 1(按预期将其标记为失败)
  • 根本没有退出命令(将其标记为失败)

Execute Shell 何时、如何以及为什么将我的构建标记为失败?

最佳答案

首先,将鼠标悬停在下方的灰色区域上。不是答案的一部分,但绝对必须说:

If you have a shell script that does "checkout, build, deploy" all by itself, then why are you using Jenkins? You are foregoing all the features of Jenkins that make it what it is. You might as well have a cron or an SVN post-commit hook call the script directly. Jenkins performing the SVN checkout itself is crucial. It allows the builds to be triggered only when there are changes (or on timer, or manual, if you prefer). It keeps track of changes between builds. It shows those changes, so you can see which build was for which set of changes. It emails committers when their changes caused successful or failed build (again, as configured as you prefer). It will email committers when their fixes fixed the failing build. And more and more. Jenkins archiving the artifacts also makes them available, per build, straight off Jenkins. While not as crucial as the SVN checkout, this is once again an integral part of what makes it Jenkins. Same with deploying. Unless you have a single environment, deployment usually happens to multiple environments. Jenkins can keep track of which environment a specific build (with specific set of SVN changes) is deployed it, through the use of Promotions. You are foregoing all of this. It sounds like you are told "you have to use Jenkins" but you don't really want to, and you are doing it just to get your bosses off your back, just to put a checkmark "yes, I've used Jenkins"

简短的回答是:Jenkin Execute Shell构建步骤的last命令的退出代码决定了构建步骤的成功/失败强>。 0 - 成功,任何其他 - 失败。 请注意,这是确定构建步骤的成功/失败,而不是整个作业运行。整个作业运行的成功/失败可能会进一步受到多个构建步骤以及构建后操作和插件的影响。

您提到了构建步骤'Execute shell'将构建标记为失败,因此我们将只关注单个构建步骤。如果您的 Execute shell 构建步骤只有一行调用您的 shell 脚本,那么您的 shell 脚本的退出代码将决定构建步骤的成功/失败。如果您有更多行,您的 shell 脚本执行之后,然后仔细检查它们,因为它们可能会导致失败。

最后,在这里阅读 Jenkins Build Script exits after Google Test execution 。它与您的问题没有直接关系,但请注意关于 Jenkins 启动 Execute Shell 构建步骤的部分,作为带有 /bin/sh -xe 的 shell 脚本

-e 表示 shell 脚本将 exit 失败,即使只有 1 个命令失败,even 如果您进行错误检查对于该命令(因为脚本在进行错误检查之前就退出了)。这与shell脚本的正常执行相反,shell脚本通常会打印失败命令的错误消息(或将其重定向为null并通过其他方式处理),然后继续。

要避免这种情况,请将 set +e 添加到 shell 脚本的顶部。

既然您说您的脚本完成了它应该做的所有事情,那么失败的命令很可能在脚本末尾的某个地方。也许是最后的 echo ?还是某处的文物副本?没有看到完整的控制台输出,我们只是在猜测。

请发布作业运行的控制台输出,最好也发布 shell 脚本本身,然后我们可以准确地告诉您哪一行出错了。

https://stackoverflow.com/questions/22814559/

相关文章:

git - sbt 如何从 git 中提取依赖项?

.net - NuGet 自动包还原不适用于 MSBuild

xcode - iOS5 Storyboard错误 : Storyboards are unavai

visual-studio - Visual Studio 2015 项目构建失败但没有错误

android - 任务 'app:mergeDebugResources' Crunching C

windows-7 - 如何解决 Nant 0.91 的配置错误?

c# - 调试未启动

angular - node_modules/rxjs/internal/types.d.ts(81

.net - 如何识别 DLL 是 Debug 还是 Release 构建(在 .NET 中)

build - 去构建 : "Cannot find package" (even though G