在Jenkins中，Execute Shell如何/何时将构建标记为失败？

Question

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

好的，我有一个。sh脚本，它几乎完成了Jenkins应该做的一切：

null

null

Answer 1

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

如果您有一个shell脚本可以自己完成“签出、构建、部署”，那么为什么要使用Jenkins呢？你忽略了詹金斯的所有特征，这些特征使它成为现在的样子。您还可以使用cron或SVN post-commit钩子直接调用脚本。Jenkins执行SVN签出本身是至关重要的。它只允许在发生更改时触发构建（或者在定时器上，或者手动，如果您愿意的话）。它跟踪构建之间的更改。它显示了这些更改，因此您可以看到哪个构建是针对哪组更改的。当提交者的更改导致构建成功或失败时，它会给提交者发送电子邮件（同样，按照您喜欢的配置）。当他们的修复修复了失败的构建时，它会给提交者发电子邮件。而且越来越多。Jenkins将工件存档还可以使它们在每次构建时直接从Jenkins获得。虽然不像SVN结帐那样重要，但这再次成为Jenkins的组成部分。部署也一样。除非您有一个单一环境，否则部署通常发生在多个环境中。Jenkins可以通过使用提升来跟踪特定构建（具有特定SVN更改集）在哪个环境中部署。你放弃了这一切。听起来像是有人告诉你“你必须使用詹金斯”，但你并不真的想这样做，你这么做只是为了让你的老板远离你，只是为了打一个勾号“是的，我用过詹金斯”

简单的回答是：Jenkin的Execute Shell构建步骤的最后一个命令的退出代码决定了构建步骤的成功/失败。0-成功，任何其他-失败。注意，这决定了构建步骤的成功/失败，而不是整个作业运行。整个作业运行的成功/失败进一步受到多个构建步骤、构建后操作和插件的影响。

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

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

-e意味着shell脚本将在失败时退出，即使只有一个命令失败，即使您对该命令进行了错误检查（因为脚本在进行错误检查之前就退出了）。这与正常执行shell脚本相反，后者通常打印失败命令的错误消息（或将其重定向为null并通过其他方式处理），然后继续执行。

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