set -e 的行为方式以及它在哪里破坏了你的脚本
运用 设置 -e Bash 中的 set-e 命令本应在出现任何错误时退出，从而提高脚本的安全性。但在实际工作流中，set-e 经常会以微妙、无声的方式破坏脚本。开发人员依靠 bash set -e 进行防御性脚本编写，却发现他们的 CI 作业意外退出，没有任何错误消息。
以下是 set-e bash 实际执行的操作：
- 如果任何命令返回非零状态，则退出脚本。
- 但忽略了 pipelines、条件、子 shell 和命令组，除非与 设置-o pipefail 或其他图案。
示例：静默失败
⚠️警告： 该脚本默默地失败了。
set -e
output=$(false) # fails, but script continues because it's in a subshell
next_step子shell中的错误被bash忽略，并且 下一步 无论如何都会执行，可能是因为输入错误。
如果您不完全了解何时应用以及何时默默跳过失败，这些怪癖会使 set-e 变得危险。
真实成功 CI/CD Pipeline set -e Bash 导致的故障
set -e bash 通常会导致内部最痛苦 CI/CD pipelines.
真实世界 pipeline 失败：
#!/bin/bash
set -e
npm install # works locally
npm run test || echo "Tests failed" # CI sees success even though tests failed
⚠️警告： 这导致 pipeline 尽管测试失败，但仍能通过。该命令是逻辑表达式的一部分，因此 set-e 不会触发。
另一个破坏的模式：
#!/bin/bash
set -e
mkdir output
cd output || true # suppresses error if dir is missing, breaking future steps silently
⚠️这种模式掩盖了未来错误的真正原因，使调试变得更加困难。
不安全的 bash 使用会导致关键步骤悄无声息地失败。这是一种 DevOps 反模式。
更安全的 Bash 脚本：使用陷阱和验证控制 set -e
为了使设置更安全，控制脚本何时以及如何失败。
使用 陷阱 用于错误追踪
trap 'echo "Error on line $LINENO"' ERR
set -e
some_command
结合 设置-o pipefail
set -euo pipefail
some_command | grep something
通过 管道故障, 设置-e bash 会捕获任何部分的故障 pipeline.
在执行危险命令后明确验证
result=$(risky_call)
if [[ $? -ne 0 ]]; then
echo "Call failed"
exit 1
fi
避免假设 set-e 捕获所有故障；对关键逻辑使用受控检查。
整合防御性攻击模式 CI/CD Pipelines
你无法完全避免 set-e。但你可以通过将良好的 Bash 实践嵌入到 CI/CD 工作流程。
CI/CD 提示：
- 始终将 set-e 与 管道故障 以及 陷阱 在入口脚本中。
- 明确检查环境变量和脚本结果。
- 绝大部分储备使用 开球 或记录捕获以查看退出前发生的情况。
- 隔离步骤并验证每个步骤。
更安全的CI pipeline 段
- name: Setup
run: |
set -euo pipefail
trap 'echo "Failure on line $LINENO"' ERR
./setup.sh
依赖 set -e bash 的隐性成本
它可能会有帮助，但默认情况下并不安全。如果你依赖它来处理错误 CI/CD，你很可能会错过真正的失败。
审核您的 set -e bash 使用情况：
- 绝大部分储备使用 管道故障, 陷阱以及明确的检查
- 监控命令结果，而不仅仅是退出代码
- 防止你的 CI/CD 工作在应该失败的时候却无法成功
使用 Xygeni 检测由 bash set -e 引起的隐藏逻辑错误，并使您的脚本具有弹性、可追溯性和安全性。 脚本不会说谎，但它们确实会悄无声息地失败。别让 set-e 成为原因。
