Argo CD 通知触发器调试指南argocd admin notifications trigger 命令详解与源码剖析【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd本文聚焦 Argo CD 的argocd admin notifications trigger命令组完整覆盖其命令语法、全部可用选项含从父命令继承的 40 余个标志位与两个子命令get、run的用法示例并结合 cmd/argocd/commands/admin/notifications.go、util/notification/settings/settings.go 与 notifications_catalog/triggers 内置触发器目录的源码实现说明触发器如何从 ConfigMap 加载、如何被求值、模板变量如何注入。读完本文你可以独立在集群外调试通知触发条件、定位通知为何没发出去的问题并理解底层 CLI 的装配链路。命令定位trigger 在通知命令树中的位置argocd admin notifications trigger属于argocd admin下的通知管理分支用于管理通知**触发器trigger**相关操作。根据 命令参考文档该命令本身是命令组入口不提供直接的执行逻辑其下级包含两个子命令argocd admin notifications trigger get打印已配置的触发器信息argocd admin notifications trigger run对指定触发器条件进行求值并打印结果。其父命令 argocd admin notifications 的描述是Set of CLI commands that helps manage notifications settings一组帮助管理通知设置的 CLI 命令另含template子命令族。argocd admin notifications trigger [flags]从源码看整棵通知命令树并非 Argo CD 手写而是复用notifications-engine库的cmd.NewToolsCommand工厂动态生成的。在 NewNotificationsCommand 中可以确认这一点toolsCommand : cmd.NewToolsCommand( notifications, argocd admin notifications, applications, // GVR: argoproj.io/v1alpha1/applications settings.GetFactorySettingsForCLI(func() service.Service { return argocdService }, argocd-notifications-secret, argocd-notifications-cm, false), func(_ context.Context, clientConfig clientcmd.ClientConfig) { ... })这行代码同时揭示了两个默认资源名触发器与模板配置读取自 ConfigMapargocd-notifications-cm凭据webhook token 等读取自 Secretargocd-notifications-secret。这也解释了为什么--config-map与--secret两个标志位的帮助文案直接写着argocd-notifications-cm.yaml file path和argocd-notifications-secret.yaml file path。trigger 命令自身的选项trigger命令组自身只暴露一个选项-h, --help help for trigger其余全部选项均从父命令argocd admin notifications及更上层的argocd admin/ 根命令继承。以下按功能域将原文档 完整选项列表 分类整理描述与官方文档保持一致。Kubernetes API 访问类触发器调试命令不走 Argo CD API Server而是直连 Kubernetes需要admin权限或相应 RBAC因此 kubeconfig 系列选项是核心标志位说明--kubeconfig stringkubeconfig 文件路径仅集群外必需--kube-context string指定使用的 kube-context--context string要使用的 kubeconfig context 名称--cluster string要使用的 kubeconfig cluster 名称--user string要使用的 kubeconfig user 名称--server stringKubernetes API Server 地址和端口--certificate-authority string证书颁发机构证书文件路径--client-certificate stringTLS 客户端证书文件路径--client-key stringTLS 客户端私钥文件路径--server-crt string服务端证书文件-n, --namespace string本次 CLI 请求的命名空间作用域--insecure-skip-tls-verify为 true 时不校验服务端证书有效性会使 HTTPS 连接不安全--password string访问 API Server 的基本认证密码--username string访问 API Server 的基本认证用户名--token string访问 API Server 的 Bearer token--core置 true 时 CLI 直接和 Kubernetes 通信而非 Argo CD API Server--as string/--as-uid string/--as-group stringArray操作时模拟指定用户名 / UID / 组可重复指定多个组Argo CD 服务端连接类虽然trigger子命令主要与 K8s 交互但选项集中仍保留了指向 Argo CD Server / Repo Server 的标志位部分用于装配service.Service见下文源码剖析标志位说明--argocd-context string要使用的 Argo-CD 服务器上下文名称--argocd-repo-server stringArgo CD repo server 地址默认argocd-repo-server:8081--argocd-repo-server-plaintext使用明文非 TLS客户端连接 repo server--server-name stringArgo CD API server 名称Helm chart 安装且名称标签不同时设置或设置环境变量ARGOCD_SERVER_NAME默认argocd-server--repo-server-name stringArgo CD Repo server 名称同上环境变量ARGOCD_REPO_SERVER_NAME默认argocd-repo-server--controller-name stringApplication controller 名称环境变量ARGOCD_APPLICATION_CONTROLLER_NAME默认argocd-application-controller--redis-name stringRedis deployment 名称环境变量ARGOCD_REDIS_NAME默认argocd-redis--redis-haproxy-name stringRedis HA Proxy 名称环境变量ARGOCD_REDIS_HAPROXY_NAME默认argocd-redis-ha-haproxy--redis-compress stringApplication controller 启用 redis 压缩时使用可选值gzip/none默认gzip--grpc-web启用 gRPC-web 协议适用于 Argo CD server 位于不支持 HTTP2 的代理之后--grpc-web-root-path string启用 gRPC-web 并设置 web root--port-forward通过端口转发连接随机 argocd-server 端口--port-forward-namespace string端口转发使用的命名空间--plaintext禁用 TLS--insecure跳过服务端证书与域名校验--auth-token string认证 token也可设置环境变量ARGOCD_AUTH_TOKEN--config stringArgo CD 配置文件路径文档中默认值/home/user/.config/argocd/config为生成文档中的占位家目录实际以当前用户主目录为准通知配置类trigger 子命令的关键选项标志位说明--config-map string指定argocd-notifications-cm.yaml文件路径用于在不读取集群内 ConfigMap 的场景下从本地文件加载触发器/模板配置--secret string指定argocd-notifications-secret.yaml文件路径传入:empty表示使用空 Secret网络重试与超时刻类标志位说明--http-retry-max int建立到 Argo CD server 的 HTTP 连接的最大重试次数--request-timeout string单个服务端请求的等待时长非零值需带时间单位如1s、2m、3h零值表示不超时默认0--disable-compression为 true 时对所有请求的响应禁用压缩--proxy-url string若提供将通过该代理 URL 连接-H, --header strings为 Argo CD CLI 发起的所有请求设置附加请求头可重复也支持逗号分隔--prompts-enabled强制开启/禁用可选的交互式提示覆盖本地配置未指定时使用本地配置默认 false日志类标志位说明--logformat string日志格式可选json/text默认json--loglevel string日志级别可选debug/info/warn/error默认info注意上述--client-crt、--client-crt-key、--tls-server-name等 TLS 标志位同样出现在原文档继承选项列表中其中--tls-server-name用于在验证服务端证书时指定替代主机名未提供时使用联系服务器所用的主机名。此外 父命令文档还列出了--repo-server-ca-cert-path、--repo-server-client-cert-path默认/app/config/reposerver/mtls/client.crt、--repo-server-client-cert-key-path默认/app/config/reposerver/mtls/client.key三个 mTLS 相关标志位用于在集群外场景下配置到 repo-server 的证书校验与双向认证。子命令一trigger get —— 查看已配置的触发器get子命令用于列出argocd-notifications-cm中定义的全部触发器。语法与示例引自 trigger get 文档argocd admin notifications trigger get [flags] # 打印所有触发器 argocd admin notifications trigger get # 以 YAML 格式打印 on-sync-failed 触发器定义 argocd admin notifications trigger get on-sync-failed -oyaml专有选项只有一个-h, --help help for get -o, --output string 输出格式可选 json|yaml|wide|name默认 wide典型排查用法当应用同步失败却没有收到预期的失败通知时先运行argocd admin notifications trigger get确认on-sync-failed等触发器确实存在且未被裁剪再用-oyaml导出完整定义核对when条件、send引用的模板名与oncePer去重键是否与预期一致。子命令二trigger run —— 离线求值触发器条件run子命令是调试通知逻辑的核心工具它接收一个触发器名和一个 Application 资源文件在本地对该触发器的when条件求值并打印结果用于回答如果现在是这个 Application 状态这个触发器会不会命中的问题。语法与示例引自 trigger run 文档argocd admin notifications trigger run NAME RESOURCE_NAME [flags] # 执行 argocd-notification-cm ConfigMap 中配置的触发器 argocd admin notifications trigger run on-sync-status-unknown ./sample-app.yaml # 使用 my-config-map.yaml 替代默认 ConfigMap 执行触发器 argocd admin notifications trigger run on-sync-status-unknown ./sample-app.yaml \ --config-map ./my-config-map.yaml要点说明NAME是触发器名如on-sync-status-unknownRESOURCE_NAME是本地 Application YAML 文件路径触发器定义默认从集群内的argocd-notifications-cmConfigMap 读取可通过--config-map ./my-config-map.yaml指向本地文件便于在修改配置尚未下发到集群时先行验证凭据默认从argocd-notifications-secret读取本地调试时可用--secret ./my-secret.yaml指定文件或传--secret :empty使用空 Secret注意依赖secrets变量的模板/上下文在无 Secret 时不可用见下文变量注入说明。从源码可以确认求值时模板变量是如何组装的。settings.go 中的 GetFactorySettingsForCLI 返回的InitGetVars回调中initGetVars 为每次求值构造了如下变量集vars : map[string]any{ app: obj, // 传入的 Application 对象 context: injectLegacyVar(context, dest.Service), // 来自 ConfigMap data[context] 的上下文 secrets: secret.Data, // argocd-notifications-secret 的数据 }并且 getAppProjectForTemplate 会额外查询app.spec.project指向的 AppProject5 秒超时项目名缺省为default把appProject也注入变量。这就解释了触发器条件里为什么能直接写app.status.operationState.phase这类表达式——run时传入的 YAML 对象整体作为app变量参与条件计算条件表达式由 notifications-engine 的表达式引擎Go Template 表达式执行。内置触发器参考notifications_catalog/triggers仓库自带一份开箱即用的触发器目录 notifications_catalog/triggers与通知目录 notifications_catalog/install.yaml 配套包含 8 个触发器on-created.yaml、on-deleted.yaml、on-deployed.yaml、on-health-degraded.yaml、on-sync-failed.yaml、on-sync-running.yaml、on-sync-status-unknown.yaml、on-sync-succeeded.yaml。挑三个最具代表性的说明触发器字段的写法on-sync-failed—— 同步失败时触发且按同步 revision 去重- when: app.status.operationState ! nil and app.status.operationState.phase in [Error, Failed] description: Application syncing has failed send: [app-sync-failed] oncePer: app.status.operationState?.syncResult?.revisionon-deployed—— 同步成功且健康并加入了对健康状态时间窗的判断防止重复触发- when: app.status.operationState ! nil and app.status.operationState.phase in [Succeeded] and app.status.health.status Healthy and (!time.Parse(app.status.health.lastTransitionTime).Add(1 * time.Minute).Before(time.Parse(app.status.operationState.finishedAt)) or time.Parse(app.status.health.lastTransitionTime).Before(time.Parse(app.status.operationState.startedAt))) description: Application is synced and healthy. Triggered once per commit. send: [app-deployed] oncePer: app.status.operationState?.syncResult?.revisionon-health-degraded—— 最简形态只判健康度- when: app.status.health.status Degraded description: Application has degraded send: [app-health-degraded] oncePer: app.status.operationState?.syncResult?.revision可以看到三个字段分工明确when是布尔表达式send是要发送的模板名列表如app-sync-failed模板定义在 ConfigMap 的templates:段oncePer是去重键——表达式取值不变则不重复发送。用trigger run name app.yaml逐一验证这些条件是排查触发器存在但不发送问题的标准动作。源码剖析CLI 如何装配出这套命令回到 cmd/argocd/commands/admin/notifications.gotrigger get/trigger run的父命令argocd admin notifications的装配逻辑值得逐段看懒初始化的 Argo CD 服务。cmd.NewToolsCommand的最后一个参数是一个惰性初始化闭包只有真正需要如trigger run求值时要查询 AppProject才执行解析 kubeconfig、解析命名空间构造到 repo-server 的 gRPC 客户端集apiclient.NewRepoServerClientset(argocdRepoServer, 5, tlsConfig)其中5为连接超时秒数再通过 dynamic client 组装service.NewArgoCDService(...)。这对应 util/notification/settings/settings.go 中GetFactorySettingsForCLI的注释allows the initialization of argocdService to be deferred until it is used。repo-server 连接标志位。命令组额外注册了--argocd-repo-server默认取common.DefaultRepoServerAddr即argocd-repo-server:8081与--argocd-repo-server-plaintext两个持久标志位分别控制 repo-server 地址与是否关闭 TLS。弃用标志位。--argocd-repo-server-strict-tls在注册后立即被MarkDeprecated替代方案是--argocd-repo-server-ca-cert-path见 第 78-84 行这与 父命令文档中出现的--repo-server-ca-cert-path选项相互印证。严格校验时的证书加载。当启用严格 TLS 校验且未显式提供证书池时代码会从ARGO_APP_CONFIG_PATH默认/app/config下的reposerver/tls/tls.crt与ca.crt加载 X.509 证书池——这是为在集群内运行的场景预置的默认路径。表达式求值入口。InitGetVars最终调用 expression.Spawn 返回变量访问器notifications-engine 用它把app、context、secrets、appProject暴露给触发器when表达式与模板渲染。值得注意的是--config-map/--secret两个标志位由notifications-engine的NewToolsCommand统一注册因此它们出现在argocd admin notifications及其全部子命令上触发器文档中Execute trigger configured in argocd-notification-cm ConfigMap的示例注释与源码中硬编码的默认名argocd-notifications-cm之间存在单数/复数差异以 notifications.go 源码 中的argocd-notifications-cm为准。实操建议与适用边界权限前提argocd admin notifications trigger需要能够访问 Argo CD 所在命名空间的 kubeconfig 凭证读取argocd-notifications-cm/argocd-notifications-secret、查询 AppProject并非普通argocd login后的 API 权限命名空间使用-n, --namespace指定 Argo CD 安装命名空间避免在多 Argo CD 实例集群中取错 ConfigMap本地验证闭环修改 ConfigMap 前先导出为本地 YAML用trigger get -oyaml核对现状再用trigger run对代表性 Application 快照argocd app get name -o yaml导出离线求值确认无误后下发空 Secret 场景trigger run在本地无集群 Secret 时传--secret :empty可正常求值不依赖secrets变量的触发器条件但若表达式或模板引用了secrets中的值则会失败——这是求值通过但实际通知仍缺 token类问题的常见根源依赖版本该命令树的行为由go.mod中引入的notifications-engine库版本决定当前仓库 go.mod 中为github.com/argoproj/notifications-engine v0.5.1-0.20260503100631-0cff13b8a717升级该依赖时when表达式的函数集合可能变化跨仓库验证行为时请以本仓库锁定版本为基准。小结argocd admin notifications trigger命令组虽然入口命令只有一个-h选项但其下get与run两个子命令配合--config-map/--secret/-n等继承选项构成了完整的触发器查看—离线求值调试闭环而源码层面notifications-engine 的NewToolsCommand工厂 Argo CD 的 GetFactorySettingsForCLI 变量注入决定了触发器条件求值时可见的app/context/secrets/appProject四类变量。掌握这两层信息再配合 notifications_catalog/triggers 中的 8 个内置触发器样例即可系统性地排查 Argo CD 通知该发没发、不该发乱发的两类问题。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Argo CD 通知触发器调试指南：argocd admin notifications trigger 命令详解与源码剖析
Argo CD 通知触发器调试指南argocd admin notifications trigger 命令详解与源码剖析【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd本文聚焦 Argo CD 的argocd admin notifications trigger命令组完整覆盖其命令语法、全部可用选项含从父命令继承的 40 余个标志位与两个子命令get、run的用法示例并结合 cmd/argocd/commands/admin/notifications.go、util/notification/settings/settings.go 与 notifications_catalog/triggers 内置触发器目录的源码实现说明触发器如何从 ConfigMap 加载、如何被求值、模板变量如何注入。读完本文你可以独立在集群外调试通知触发条件、定位通知为何没发出去的问题并理解底层 CLI 的装配链路。命令定位trigger 在通知命令树中的位置argocd admin notifications trigger属于argocd admin下的通知管理分支用于管理通知**触发器trigger**相关操作。根据 命令参考文档该命令本身是命令组入口不提供直接的执行逻辑其下级包含两个子命令argocd admin notifications trigger get打印已配置的触发器信息argocd admin notifications trigger run对指定触发器条件进行求值并打印结果。其父命令 argocd admin notifications 的描述是Set of CLI commands that helps manage notifications settings一组帮助管理通知设置的 CLI 命令另含template子命令族。argocd admin notifications trigger [flags]从源码看整棵通知命令树并非 Argo CD 手写而是复用notifications-engine库的cmd.NewToolsCommand工厂动态生成的。在 NewNotificationsCommand 中可以确认这一点toolsCommand : cmd.NewToolsCommand( notifications, argocd admin notifications, applications, // GVR: argoproj.io/v1alpha1/applications settings.GetFactorySettingsForCLI(func() service.Service { return argocdService }, argocd-notifications-secret, argocd-notifications-cm, false), func(_ context.Context, clientConfig clientcmd.ClientConfig) { ... })这行代码同时揭示了两个默认资源名触发器与模板配置读取自 ConfigMapargocd-notifications-cm凭据webhook token 等读取自 Secretargocd-notifications-secret。这也解释了为什么--config-map与--secret两个标志位的帮助文案直接写着argocd-notifications-cm.yaml file path和argocd-notifications-secret.yaml file path。trigger 命令自身的选项trigger命令组自身只暴露一个选项-h, --help help for trigger其余全部选项均从父命令argocd admin notifications及更上层的argocd admin/ 根命令继承。以下按功能域将原文档 完整选项列表 分类整理描述与官方文档保持一致。Kubernetes API 访问类触发器调试命令不走 Argo CD API Server而是直连 Kubernetes需要admin权限或相应 RBAC因此 kubeconfig 系列选项是核心标志位说明--kubeconfig stringkubeconfig 文件路径仅集群外必需--kube-context string指定使用的 kube-context--context string要使用的 kubeconfig context 名称--cluster string要使用的 kubeconfig cluster 名称--user string要使用的 kubeconfig user 名称--server stringKubernetes API Server 地址和端口--certificate-authority string证书颁发机构证书文件路径--client-certificate stringTLS 客户端证书文件路径--client-key stringTLS 客户端私钥文件路径--server-crt string服务端证书文件-n, --namespace string本次 CLI 请求的命名空间作用域--insecure-skip-tls-verify为 true 时不校验服务端证书有效性会使 HTTPS 连接不安全--password string访问 API Server 的基本认证密码--username string访问 API Server 的基本认证用户名--token string访问 API Server 的 Bearer token--core置 true 时 CLI 直接和 Kubernetes 通信而非 Argo CD API Server--as string/--as-uid string/--as-group stringArray操作时模拟指定用户名 / UID / 组可重复指定多个组Argo CD 服务端连接类虽然trigger子命令主要与 K8s 交互但选项集中仍保留了指向 Argo CD Server / Repo Server 的标志位部分用于装配service.Service见下文源码剖析标志位说明--argocd-context string要使用的 Argo-CD 服务器上下文名称--argocd-repo-server stringArgo CD repo server 地址默认argocd-repo-server:8081--argocd-repo-server-plaintext使用明文非 TLS客户端连接 repo server--server-name stringArgo CD API server 名称Helm chart 安装且名称标签不同时设置或设置环境变量ARGOCD_SERVER_NAME默认argocd-server--repo-server-name stringArgo CD Repo server 名称同上环境变量ARGOCD_REPO_SERVER_NAME默认argocd-repo-server--controller-name stringApplication controller 名称环境变量ARGOCD_APPLICATION_CONTROLLER_NAME默认argocd-application-controller--redis-name stringRedis deployment 名称环境变量ARGOCD_REDIS_NAME默认argocd-redis--redis-haproxy-name stringRedis HA Proxy 名称环境变量ARGOCD_REDIS_HAPROXY_NAME默认argocd-redis-ha-haproxy--redis-compress stringApplication controller 启用 redis 压缩时使用可选值gzip/none默认gzip--grpc-web启用 gRPC-web 协议适用于 Argo CD server 位于不支持 HTTP2 的代理之后--grpc-web-root-path string启用 gRPC-web 并设置 web root--port-forward通过端口转发连接随机 argocd-server 端口--port-forward-namespace string端口转发使用的命名空间--plaintext禁用 TLS--insecure跳过服务端证书与域名校验--auth-token string认证 token也可设置环境变量ARGOCD_AUTH_TOKEN--config stringArgo CD 配置文件路径文档中默认值/home/user/.config/argocd/config为生成文档中的占位家目录实际以当前用户主目录为准通知配置类trigger 子命令的关键选项标志位说明--config-map string指定argocd-notifications-cm.yaml文件路径用于在不读取集群内 ConfigMap 的场景下从本地文件加载触发器/模板配置--secret string指定argocd-notifications-secret.yaml文件路径传入:empty表示使用空 Secret网络重试与超时刻类标志位说明--http-retry-max int建立到 Argo CD server 的 HTTP 连接的最大重试次数--request-timeout string单个服务端请求的等待时长非零值需带时间单位如1s、2m、3h零值表示不超时默认0--disable-compression为 true 时对所有请求的响应禁用压缩--proxy-url string若提供将通过该代理 URL 连接-H, --header strings为 Argo CD CLI 发起的所有请求设置附加请求头可重复也支持逗号分隔--prompts-enabled强制开启/禁用可选的交互式提示覆盖本地配置未指定时使用本地配置默认 false日志类标志位说明--logformat string日志格式可选json/text默认json--loglevel string日志级别可选debug/info/warn/error默认info注意上述--client-crt、--client-crt-key、--tls-server-name等 TLS 标志位同样出现在原文档继承选项列表中其中--tls-server-name用于在验证服务端证书时指定替代主机名未提供时使用联系服务器所用的主机名。此外 父命令文档还列出了--repo-server-ca-cert-path、--repo-server-client-cert-path默认/app/config/reposerver/mtls/client.crt、--repo-server-client-cert-key-path默认/app/config/reposerver/mtls/client.key三个 mTLS 相关标志位用于在集群外场景下配置到 repo-server 的证书校验与双向认证。子命令一trigger get —— 查看已配置的触发器get子命令用于列出argocd-notifications-cm中定义的全部触发器。语法与示例引自 trigger get 文档argocd admin notifications trigger get [flags] # 打印所有触发器 argocd admin notifications trigger get # 以 YAML 格式打印 on-sync-failed 触发器定义 argocd admin notifications trigger get on-sync-failed -oyaml专有选项只有一个-h, --help help for get -o, --output string 输出格式可选 json|yaml|wide|name默认 wide典型排查用法当应用同步失败却没有收到预期的失败通知时先运行argocd admin notifications trigger get确认on-sync-failed等触发器确实存在且未被裁剪再用-oyaml导出完整定义核对when条件、send引用的模板名与oncePer去重键是否与预期一致。子命令二trigger run —— 离线求值触发器条件run子命令是调试通知逻辑的核心工具它接收一个触发器名和一个 Application 资源文件在本地对该触发器的when条件求值并打印结果用于回答如果现在是这个 Application 状态这个触发器会不会命中的问题。语法与示例引自 trigger run 文档argocd admin notifications trigger run NAME RESOURCE_NAME [flags] # 执行 argocd-notification-cm ConfigMap 中配置的触发器 argocd admin notifications trigger run on-sync-status-unknown ./sample-app.yaml # 使用 my-config-map.yaml 替代默认 ConfigMap 执行触发器 argocd admin notifications trigger run on-sync-status-unknown ./sample-app.yaml \ --config-map ./my-config-map.yaml要点说明NAME是触发器名如on-sync-status-unknownRESOURCE_NAME是本地 Application YAML 文件路径触发器定义默认从集群内的argocd-notifications-cmConfigMap 读取可通过--config-map ./my-config-map.yaml指向本地文件便于在修改配置尚未下发到集群时先行验证凭据默认从argocd-notifications-secret读取本地调试时可用--secret ./my-secret.yaml指定文件或传--secret :empty使用空 Secret注意依赖secrets变量的模板/上下文在无 Secret 时不可用见下文变量注入说明。从源码可以确认求值时模板变量是如何组装的。settings.go 中的 GetFactorySettingsForCLI 返回的InitGetVars回调中initGetVars 为每次求值构造了如下变量集vars : map[string]any{ app: obj, // 传入的 Application 对象 context: injectLegacyVar(context, dest.Service), // 来自 ConfigMap data[context] 的上下文 secrets: secret.Data, // argocd-notifications-secret 的数据 }并且 getAppProjectForTemplate 会额外查询app.spec.project指向的 AppProject5 秒超时项目名缺省为default把appProject也注入变量。这就解释了触发器条件里为什么能直接写app.status.operationState.phase这类表达式——run时传入的 YAML 对象整体作为app变量参与条件计算条件表达式由 notifications-engine 的表达式引擎Go Template 表达式执行。内置触发器参考notifications_catalog/triggers仓库自带一份开箱即用的触发器目录 notifications_catalog/triggers与通知目录 notifications_catalog/install.yaml 配套包含 8 个触发器on-created.yaml、on-deleted.yaml、on-deployed.yaml、on-health-degraded.yaml、on-sync-failed.yaml、on-sync-running.yaml、on-sync-status-unknown.yaml、on-sync-succeeded.yaml。挑三个最具代表性的说明触发器字段的写法on-sync-failed—— 同步失败时触发且按同步 revision 去重- when: app.status.operationState ! nil and app.status.operationState.phase in [Error, Failed] description: Application syncing has failed send: [app-sync-failed] oncePer: app.status.operationState?.syncResult?.revisionon-deployed—— 同步成功且健康并加入了对健康状态时间窗的判断防止重复触发- when: app.status.operationState ! nil and app.status.operationState.phase in [Succeeded] and app.status.health.status Healthy and (!time.Parse(app.status.health.lastTransitionTime).Add(1 * time.Minute).Before(time.Parse(app.status.operationState.finishedAt)) or time.Parse(app.status.health.lastTransitionTime).Before(time.Parse(app.status.operationState.startedAt))) description: Application is synced and healthy. Triggered once per commit. send: [app-deployed] oncePer: app.status.operationState?.syncResult?.revisionon-health-degraded—— 最简形态只判健康度- when: app.status.health.status Degraded description: Application has degraded send: [app-health-degraded] oncePer: app.status.operationState?.syncResult?.revision可以看到三个字段分工明确when是布尔表达式send是要发送的模板名列表如app-sync-failed模板定义在 ConfigMap 的templates:段oncePer是去重键——表达式取值不变则不重复发送。用trigger run name app.yaml逐一验证这些条件是排查触发器存在但不发送问题的标准动作。源码剖析CLI 如何装配出这套命令回到 cmd/argocd/commands/admin/notifications.gotrigger get/trigger run的父命令argocd admin notifications的装配逻辑值得逐段看懒初始化的 Argo CD 服务。cmd.NewToolsCommand的最后一个参数是一个惰性初始化闭包只有真正需要如trigger run求值时要查询 AppProject才执行解析 kubeconfig、解析命名空间构造到 repo-server 的 gRPC 客户端集apiclient.NewRepoServerClientset(argocdRepoServer, 5, tlsConfig)其中5为连接超时秒数再通过 dynamic client 组装service.NewArgoCDService(...)。这对应 util/notification/settings/settings.go 中GetFactorySettingsForCLI的注释allows the initialization of argocdService to be deferred until it is used。repo-server 连接标志位。命令组额外注册了--argocd-repo-server默认取common.DefaultRepoServerAddr即argocd-repo-server:8081与--argocd-repo-server-plaintext两个持久标志位分别控制 repo-server 地址与是否关闭 TLS。弃用标志位。--argocd-repo-server-strict-tls在注册后立即被MarkDeprecated替代方案是--argocd-repo-server-ca-cert-path见 第 78-84 行这与 父命令文档中出现的--repo-server-ca-cert-path选项相互印证。严格校验时的证书加载。当启用严格 TLS 校验且未显式提供证书池时代码会从ARGO_APP_CONFIG_PATH默认/app/config下的reposerver/tls/tls.crt与ca.crt加载 X.509 证书池——这是为在集群内运行的场景预置的默认路径。表达式求值入口。InitGetVars最终调用 expression.Spawn 返回变量访问器notifications-engine 用它把app、context、secrets、appProject暴露给触发器when表达式与模板渲染。值得注意的是--config-map/--secret两个标志位由notifications-engine的NewToolsCommand统一注册因此它们出现在argocd admin notifications及其全部子命令上触发器文档中Execute trigger configured in argocd-notification-cm ConfigMap的示例注释与源码中硬编码的默认名argocd-notifications-cm之间存在单数/复数差异以 notifications.go 源码 中的argocd-notifications-cm为准。实操建议与适用边界权限前提argocd admin notifications trigger需要能够访问 Argo CD 所在命名空间的 kubeconfig 凭证读取argocd-notifications-cm/argocd-notifications-secret、查询 AppProject并非普通argocd login后的 API 权限命名空间使用-n, --namespace指定 Argo CD 安装命名空间避免在多 Argo CD 实例集群中取错 ConfigMap本地验证闭环修改 ConfigMap 前先导出为本地 YAML用trigger get -oyaml核对现状再用trigger run对代表性 Application 快照argocd app get name -o yaml导出离线求值确认无误后下发空 Secret 场景trigger run在本地无集群 Secret 时传--secret :empty可正常求值不依赖secrets变量的触发器条件但若表达式或模板引用了secrets中的值则会失败——这是求值通过但实际通知仍缺 token类问题的常见根源依赖版本该命令树的行为由go.mod中引入的notifications-engine库版本决定当前仓库 go.mod 中为github.com/argoproj/notifications-engine v0.5.1-0.20260503100631-0cff13b8a717升级该依赖时when表达式的函数集合可能变化跨仓库验证行为时请以本仓库锁定版本为基准。小结argocd admin notifications trigger命令组虽然入口命令只有一个-h选项但其下get与run两个子命令配合--config-map/--secret/-n等继承选项构成了完整的触发器查看—离线求值调试闭环而源码层面notifications-engine 的NewToolsCommand工厂 Argo CD 的 GetFactorySettingsForCLI 变量注入决定了触发器条件求值时可见的app/context/secrets/appProject四类变量。掌握这两层信息再配合 notifications_catalog/triggers 中的 8 个内置触发器样例即可系统性地排查 Argo CD 通知该发没发、不该发乱发的两类问题。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考