set -e 的行為方式，以及它會在哪些地方破壞你的腳本
使用 設定 -e Bash 中的 `set-e` 指令本應在出現任何錯誤時退出腳本，從而提高安全性。但在實際工作流程中，`set-e` 指令常常以不易察覺的方式破壞腳本。開發人員依賴 `bash set -e` 指令進行防禦性腳本編寫，卻發現他們的持續整合 (CI) 作業會在沒有任何錯誤訊息的情況下意外退出。
set-e bash 實際上執行的操作如下：
- 如果任何命令返回非零狀態，則退出腳本。
- 但忽略了錯誤 pipeline除非與…配對，否則不會出現 s、條件語句、子 shell 和命令群組。 設置-o pipefail 或其他模式。
例：靜默失敗
🇧🇷警告： 此腳本運行失敗，且不作任何提示。
set -e output=$(false) # fails, but script continues because it's in a subshell next_step子 shell 中的錯誤會被 bash 忽略，並且 下一步 即使輸入錯誤，也會執行操作。
如果你不完全了解 set-e 何時適用以及何時會默默跳過失敗，那麼這些怪癖會使 set-e 變得危險。
真實 CI/CD Pipeline 使用 set -e Bash 導致的故障
設定 -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 成為罪魁禍首。
