--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。
