Execute Shell 如何/何时在 Jenkins 中将构建标记为失败? [英] How/When does Execute Shell mark a build as failure in Jenkins?

问题描述

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

The horror stories I found while searching for an answer for this one...

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

OK, I have a .sh script which pretty much does everything Jenkins supposed to do:

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

所以在 Jenkins 中，我只需要通过在 Execute Shell 命令中运行脚本来构建"项目.运行脚本(下载源代码，构建/部署项目)，但随后将构建标记为失败:构建步骤执行 shell"将构建标记为失败即使脚本成功运行！我尝试关闭脚本:

So in Jenkins I only have to 'build' the project by running the script in an Execute Shell command. The script is ran (the sources are downloaded, the project is build/deploy) but then it marks the build as a failure: Build step 'Execute shell' marked build as failure Even if the script was successfully ran! I tried closing the script with:

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

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

When, how and why does Execute Shell mark my build as a failure?

推荐答案

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

First things first, hover the mouse over the grey area below. Not part of the answer, but absolutely has to be said:

如果你有一个 shell 脚本可以自己完成结账、构建、部署"，那么你为什么要使用 Jenkins?您放弃了 Jenkins 的所有功能，使其成为现在的样子.您也可以使用 cron 或 SVN post-commit hook 直接调用脚本.Jenkins 执行 SVN 结帐本身是至关重要的.它允许仅在发生更改时(或按计时器或手动，如果您愿意)触发构建.它跟踪构建之间的更改.它显示了这些更改，因此您可以查看哪个版本针对哪组更改.当提交者的更改导致构建成功或失败时，它会向提交者发送电子邮件(同样，根据您的喜好进行配置).当提交者的修复修复了失败的构建时，它将通过电子邮件发送给提交者.而且越来越多.Jenkins 归档工件也使它们在每次构建时直接从 Jenkins 可用.虽然不如 SVN 结账那么重要，但它再次成为 Jenkins 不可或缺的一部分.与部署相同.除非您只有一个环境，否则部署通常会发生在多个环境中.Jenkins 可以通过使用 Promotions 跟踪特定构建(具有特定的 SVN 更改集)部署在哪个环境中.你放弃了这一切.听起来你被告知你必须使用詹金斯"，但你并不是真的想要，你这样做只是为了让你的老板摆脱困境，只是为了勾选是的，我用过詹金斯"

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 - 成功，任何其他 - 失败.请注意，这决定了构建步骤的成功/失败，而不是整个作业运行.多个构建步骤、构建后操作和插件会进一步影响整个作业运行的成功/失败.

The short answer is: the exit code of last command of the Jenkin's Execute Shell build step is what determines the success/failure of the Build Step. 0 - success, anything else - failure. Note, this is determining the success/failure of the build step, not the whole job run. The success/failure of the whole job run can further be affected by multiple build steps, and post-build actions and plugins.

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

You've mentioned Build step 'Execute shell' marked build as failure, so we will focus just on a single build step. If your Execute shell build step only has a single line that calls your shell script, then the exit code of your shell script will determine the success/failure of the build step. If you have more lines, after your shell script execution, then carefully review them, as they are the ones that could be causing failure.

最后，请阅读这里Jenkins 构建脚本在 Google 测试执行后退出.它与您的问题没有直接关系，但请注意关于 Jenkins 启动 Execute Shell 构建步骤的部分，作为带有 /bin/sh -xe 的 shell 脚本

Finally, have a read here Jenkins Build Script exits after Google Test execution. It is not directly related to your question, but note that part about Jenkins launching the Execute Shell build step, as a shell script with /bin/sh -xe

-e 意味着 shell 脚本将退出失败，即使只有 1 个命令失败，甚至如果你做错误检查对于该命令(因为脚本在进行错误检查之前退出).这与shell脚本的正常执行相反，它通常会打印失败命令的错误消息(或将其重定向为null并通过其他方式处理)，然后继续.

The -e means that the shell script will exit with failure, even if just 1 command fails, even if you do error checking for that command (because the script exits before it gets to your error checking). This is contrary to normal execution of shell scripts, which usually print the error message for the failed command (or redirect it to null and handle it by other means), and continue.

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

To circumvent this, add set +e to the top of your shell script.

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

Since you say your script does all it is supposed to do, chances are the failing command is somewhere at the end of the script. Maybe a final echo? Or copy of artifacts somewhere? Without seeing the full console output, we are just guessing.

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

Please post the job run's console output, and preferably the shell script itself too, and then we could tell you exactly which line is failing.

这篇关于Execute Shell 如何/何时在 Jenkins 中将构建标记为失败?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！