我在寻找这个答案时发现的恐怖故事......
好的,我有一个.sh脚本,几乎可以完成Jenkins应该做的所有事情:
检查SVN的来源
建立项目
部署项目
自己清理
所以在Jenkins中我只需要通过在Execute Shell命令中运行脚本来"构建"项目.脚本已运行(源代码已下载,项目已构建/部署)但随后它将构建标记为失败:构建步骤"执行shell"将构建标记为失败即使脚本已成功运行!我尝试用以下方法关闭脚本:
退出0(仍将其标记为失败)
退出1(按预期标记为失败)
根本没有退出命令(将其标记为失败)
Execute Shell何时,如何以及为何将我的构建标记为失败？
首先,将鼠标悬停在下面的灰色区域上.不是答案的一部分,但绝对必须说:
如果你有一个单独执行"checkout,build,deploy"的shell脚本,那你为什么要使用Jenkins？你已经了解了詹金斯的所有功能,使它成为现实.你可能还有一个cron或一个SVN post-commit钩子直接调用脚本.Jenkins执行SVN结账本身至关重要.它允许仅在有更改时触发构建(或者如果您愿意,可以在计时器或手动上触发).它跟踪构建之间的变化.它显示了这些更改,因此您可以看到哪个版本适用于哪组更改.当它们的更改导致构建成功或失败时,它会通过电子邮件发送提交者(同样,根据您的喜好进行配置).当他们的修复修复了失败的构建时,它将通过电子邮件发送提交者.而且越来越多.詹金斯归档这些文物也使得它们可以在每个版本中直接使用Jenkins.虽然不如SVN结账那么重要,但这再次成为Jenkins的重要组成部分.与部署相同.除非您拥有单一环境,否则部署通常会发生在多个环境中.通过使用Promotions,Jenkins可以跟踪特定构建(具有特定的SVN更改集)的环境.你已经完成了这一切.这听起来像你被告知"你必须使用詹金斯",但你真的不想这样做,而你这样做只是为了让你的老板脱离你的背,只是勾选"是的,我用过詹金斯"
简短的回答是:退出代码最后的詹金的命令执行shell构建步骤是什么决定了的成功/失败生成步骤.0- 成功,anything else- 失败.注意,这是确定构建步骤的成功/失败,而不是整个作业运行.整个作业运行的成功/失败可能会受到多个构建步骤以及构建后操作和插件的影响.
你已经提到了Build step 'Execute shell' marked build as failure,所以我们只关注一个构建步骤.如果您的Execute shell构建步骤只有一行调用您的shell脚本,那么shell脚本的退出代码将确定构建步骤的成功/失败.如果在执行shell脚本后有更多行,则仔细查看它们,因为它们可能导致失败.
最后,在Google Test执行后阅读Jenkins Build Script.它与您的问题没有直接关系,但请注意关于Jenkins启动Execute Shell构建步骤的部分,作为shell脚本/bin/sh -xe
将-e在shell脚本将会手段退出失败,哪怕只是1命令失败,甚至如果你这样做,该命令错误检查(因为脚本退出它到达你的错误检查之前).这与正常执行shell脚本相反,shell脚本通常会打印失败命令的错误消息(或将其重定向为null并通过其他方式处理它),然后继续.
要绕过这一点,请添加set +e到shell脚本的顶部.
既然你说你的脚本完成了应该做的所有事情,那么失败的命令可能就在脚本末尾的某个地方.也许是最后的回声？或者在某处复制文物？没有看到完整的控制台输出,我们只是在猜测.
请发布作业运行的控制台输出,最好是shell脚本本身,然后我们可以确切地告诉您哪条线路出现故障.
简单而简短的回答你的问题是
请在"执行shell"构建步骤中添加以下行.
#!/bin/sh
现在让我向您解释为什么我们需要"Execute Shell"构建作业的这一行.
默认情况下,Jenkins接受/bin/sh -xe并且这意味着-x将打印每个命令.另一个选项-e会导致shell在任何命令以非零(当任何命令失败时)退出代码时立即停止运行脚本.
因此通过添加#!/bin/sh将允许您执行没有选项.
京公网安备 11010802040832号 | 京ICP备19059560号-6 