Linux popeye 的 –set-exit-code-on-issue 与 CI 门禁实践

–set-exit-code-on-issue 不生效是因为默认仅 Error 触发非零退出码，该标志仅将 warning 纳入，但不处理 info；需配合 –all-Namespaces、显式 namespace、足够 rbac 权限及新版 popeye 才能可靠生效。

为什么 --set-exit-code-on-issue 在 CI 里经常不生效

它本身不改变 popeye 的默认退出码逻辑，只在检测到 issue 时把 exit code 设为 1（而非默认的 0），但前提是 popeye 真的“检测到了 issue”——而默认配置下，很多问题被归类为 warning 或 info，不会触发该标志。

实操建议：

• popeye 默认只对 error 级别 issue 设置非零退出码；--set-exit-code-on-issue 会把 warning 和 error 都纳入，但不会影响 info
• 必须配合 --all-namespaces 或明确指定 namespace，否则可能漏扫、看似没报错实则没跑全
• CI 中建议显式加 --no-color --no-header，避免 ANSI 控制字符干扰日志解析
• 常见错误现象：echo $? 返回 0，但日志里明明有 “WARN Deployment has no Resource limits” —— 这是因为没加 --set-exit-code-on-issue，或 popeye 版本太老（

popeye scan 的 exit code 到底怎么分的

不是简单“有/无问题”，而是按 severity 分层返回：0（clean）、1（warning or error with --set-exit-code-on-issue）、2（scan failed，比如 kubeconfig 无效、API server 不通）。

实操建议：

• CI 脚本里不要只判断 [[ $? -ne 0 ]]，应区分是配置失败（exit 2）还是策略问题（exit 1），后者才该阻断流水线
• popeye scan -f cluster.yaml 这种离线模式下，--set-exit-code-on-issue 依然生效，但 issue 类型仅限于 YAML 结构和基础合规性，不涉及 runtime 状态
• 不同版本行为差异：v4.11 及之前，--set-exit-code-on-issue 对 warning 无效；v4.12+ 才真正覆盖 warning

CI 里怎么让 popeye 真正“卡住”流水线

关键不是加一个 flag，而是把扫描结果和 exit code 绑定到 pipeline 的 gate 条件中，并屏蔽误报路径。

实操建议：

• 用 --exclude 明确跳过已知暂不修复的资源，例如 --exclude deployments/nginx-ingress，避免因历史债务导致每次失败
• 推荐组合命令：popeye scan --set-exit-code-on-issue --all-namespaces --no-color --no-header 2>/dev/NULL || { echo "Popeye found issues"; exit 1; }
• 注意 2>/dev/null 会吞掉真实错误（如连接失败），建议改为 2>&1 | grep -q "context deadline exceeded|connection refused" && exit 2 做前置健康检查
• github Actions / gitlab CI 中，确保 runner 安装的是二进制版 popeye（非 snap 或 brew），否则权限或路径问题会导致 exec format error

为什么本地跑出 warning，CI 却没报

大概率是环境差异：kubeconfig 权限、context 指向、集群版本、popeye 版本、甚至默认 namespace 是否一致。

实操建议：

• CI 中显式设置 KUBECONFIG 和 POPEYE_NAMESPACE，不要依赖 kubectl config current-context 的隐式行为
• 用 popeye version 校验 CI 环境版本，v4.13 修复了对 kubernetes 1.28+ CRD 的误报，老版本可能根本扫不出某些 issue
• 如果使用 helm template + popeye，注意 helm 渲染后可能缺失 namespace 字段，导致 popeye 跳过扫描——加 --namespace default 强制指定

最常被忽略的一点：popeye 的 issue 检测高度依赖 RBAC 权限。CI 使用的 service account 如果没被授予 list 所有 relevant resources（比如 podsecuritypolicies 已废弃但旧集群仍有），它就安静地跳过，既不报错也不报 warning。