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

如果您有一个shell脚本自己单独执行“签出，构建，部署”，那么为什么要使用Jenkins？您将继承詹金斯的所有功能，使其成为现实。
您可能还有cron或SVN提交后钩子，请直接调用脚本
。詹金斯（Jenkins）执行SVN结帐本身至关重要。它允许仅在有更改时（或按计时器或手动（如果您愿意））触发构建。它跟踪构建之间的更改。它显示了这些更改，因此您可以查看哪个构建适用于哪个更改集。当提交者的更改导致构建成功或失败时，它将通过电子邮件发送给提交者（同样，根据您的喜好进行配置）。当修复程序修复了失败的构建后，它将向提交者发送电子邮件。越来越多。Jenkins归档工件也使Jenkins每次构建时都可以使用它们。尽管不像SVN结帐那样重要，但这再次成为使其成为Jenkins不可或缺的一部分。与部署相同。除非您有一个环境，否则部署通常会发生在多个环境中。Jenkins可以通过使用Promotions来跟踪部署了特定版本（具有特定的SVN更改集）的环境。您正在接受所有这些。听起来您被告知“您必须使用Jenkins”，但您实际上并不想这么做，而这样做只是为了让您的老板松了一口气，只打了勾号：“是的，我已经使用了Jenkins”

简短的答案是：Jenkin的 Execute Shell 构建步骤的 最后一个 命令的退出代码是确定 Build Step成功/失败的原因。-成功-失败 注意，这是确定 构建步骤 的成功/失败，而不是整个 作业的运行。整个作业运行的成功/失败会进一步受到多个构建步骤以及构建后操作和插件的影响。 0``anything else

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

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

为了避免这种情况，请添加set +e到您的Shell脚本的顶部。

由于您说脚本完成了所有应做的工作，因此失败的命令很可能位于脚本末尾。也许是最后的回声？还是某处的文物副本？没有看到完整的控制台输出，我们只是在猜测。

请发布作业运行的控制台输出，最好也发布shell脚本本身，然后我们才能确切告诉您哪一行失败。