Gitlab CI 忽略 1 以外的脚本退出代码

Posted 2023-02-19

【中文标题】Gitlab CI 忽略 1 以外的脚本退出代码

【英文标题】：Gitlab CI ignores script exit code other than 1

【发布时间】：2021-07-08 23:36:37

【问题描述】：

我正在尝试建立一个 gitlab 管道，以便某些 exit_codes 可以用于正在执行的脚本。 我已经尝试过 shell 和 ruby​​ 脚本，但两者似乎都有相同的行为。

如您所见，我只是在执行脚本，仅此而已，我的期望是，最后执行的脚本被用作作业的退出状态。

在脚本中我只调用“exit 64”，在这种情况下这应该是“允许的失败”，但是管道日志显示作业由于退出代码 1 而失败：

如何让 gitlab 接受此（或 ruby​​）脚本的退出代码作为作业退出代码？

【问题讨论】：

不要将代码发布为屏幕截图。听起来您从脚本中收到错误代码 1 而不是 64。你确定那里没有失败吗？

【参考方案1】：

我找到了解决这个问题的方法，显然 gitlab-runner 使用“-e”标志，这意味着任何非 0 退出代码都会取消作业。 这可以通过使用“set +e”来更新，但是您仍然需要捕获作业的实际退出代码。

使用 $?在两个不同的配置行中不起作用，因为 gitlab 会在它们之间“回显”调用。

所以需要直接捕获退出代码，例如：

  script:
    - ruby "ci/example.rb" || EXIT_CODE=$?
    - exit $EXIT_CODE

【讨论】：

我也有同样的问题。您能否提供有关您在哪里运行 set +e 的更多信息，或者您是否知道某个配置的位置？此外，如果给出了不允许的非零退出代码，会发生什么情况？我认为这对您的答案很有用。

【参考方案2】：

这是我关闭早期故障并稍后检查结果代码的技巧：

  script:
    - set +e +o pipefail
    - python missing_module.py 2>&1 | grep found; result=$?
    - set -e -o pipefail
    - "[ $result == 0 ]"

这将关闭提前退出并运行我们认为如果错误文本中出现“found”则失败可接受的命令。然后它会重新打开提前退出并测试我们保存的退出代码是否正确。