首先,将鼠标悬停在下面的灰色区域上方。这不是答案的一部分,但必须明确:
如果你拥有一个能够自行执行“检出、构建、部署”的shell脚本,那你为什么还要使用Jenkins呢?这样做就放弃了Jenkins的所有特性。你不如直接让cron或者SVN的后提交挂钩直接调用该脚本。Jenkins执行SVN检出非常重要。它可以在发生变更时才触发构建(或按计时器、手动方式),也会跟踪构建之间的变化,并显示这些变化,因此您可以看到哪次构建是为了哪个变更集而构建的。它会向提交者发送电子邮件,告诉他们他们的变更导致了成功或失败的构建(根据您的配置)。当提交者修复了失败的构建时,它也会发送电子邮件通知。除此之外,Jenkins还有更多功能。Jenkins归档工件使它们可以直接从Jenkins中获取,每个构建都有一个相应的工件。虽然不像SVN检出那么重要,但这同样是Jenkins的一个组成部分。部署也是一样的。除非您只有一个环境,否则部署通常会发生在多个环境中。Jenkins可以通过Promotions来跟踪特定构建(具有特定的SVN变更集)已经部署到哪个环境。你放弃了所有这些。听起来像是“你必须使用Jenkins”,但你并不想使用它,只是为了让你的老板放心,只是为了打一个勾“是的,我使用了Jenkins”。
简单来说,Jenkins的“执行Shell”构建步骤中的“last”命令的退出代码决定了“Build Step”的成功/失败。0表示成功,任何其他数字表示失败。请注意,这是确定“build step”成功/失败,而不是整个作业运行的成功/失败。整个作业运行的成功/失败还可能受到多个构建步骤、后构建操作和插件的影响。
您提到了“Build step 'Execute shell' marked build as failure”,因此我们将仅关注单个构建步骤。如果您的“执行Shell”构建步骤只有一行调用您的shell脚本,则您的shell脚本的退出代码将确定构建步骤的成功/失败。如果您有更多行在shell脚本执行之后,请仔细审查它们,因为它们可能会导致失败。
最后,阅读此处Jenkins构建脚本在Google测试执行后退出。虽然与你的问题不直接相关,但请注意关于Jenkins启动Execute Shell构建步骤的部分,作为带有/bin/sh -xe
的shell脚本。
-e
意味着即使只有一个命令失败,shell脚本也会失败退出,即使您对该命令进行错误检查(因为脚本在到达您的错误检查之前退出)。这与通常执行shell脚本的方式相反,通常会打印失败命令的错误消息(或将其重定向为空并通过其他方式处理),然后继续执行。
为了规避这种情况,请在shell脚本顶部添加set +e
。
由于您说您的脚本已完成所有应该完成的工作,所以失败的命令可能在脚本的末尾某个位置。也许是最后的echo?还是复制某个地方的artifact?如果没有看到完整的控制台输出,我们只是在猜测。
请发布作业运行的控制台输出,最好也附上shell脚本本身,这样我们就可以告诉您哪一行出错了。