PipelineRun 创建失败常见原因包括：Task 未部署、节点无匹配 label、pipelineRef.name 拼写错误、跨 namespace 创建、ServiceAccount 权限不足、未正确设置 GroupVersionKind 或 TLS 配置。
tekton pipelineRun 创建失败：常见 status.phase = "Failed" 原因
绝大多数 Tekton 流水线跑不起来，不是 Go 代码写错了，而是 PipelineRun 资源卡在 Failed 状态——这时候别急着改 Go 程序，先看日志和状态字段。
-
kubectl get pipelinerun -o wide看STATUS和STARTED时间，确认是否真被调度 -
kubectl describe pipelinerun <name>重点查Events区域，常出现failed to resolve taskref（Task没部署）或no available node（没带匹配 label 的节点） - Go 侧用
tektoncd/pipeline/pkg/client/clientset/versioned创建PipelineRun时，若spec.pipelineRef.name拼错，API server 不报错但 controller 无法关联，状态直接卡Unknown - 注意 namespace：Go 客户端创建的
PipelineRun必须和Pipeline/Task在同一 namespace，跨 ns 不支持（Tekton v0.40+ 仍不支持）
Go 中动态生成 PipelineRun：避免硬编码参数的写法
Tekton 的 PipelineRun 天然适合用 Go 动态构造，但直接拼 YAML 字符串极易出错；正确做法是用结构体 + runtime.DefaultUnstructuredConverter 或 client-go 的 scheme。
- 优先用
tektonpipelinev1.PipelineRun类型（来自github.com/tektoncd/pipeline/pkg/apis/pipeline/v1），它自带默认值和校验逻辑，比如spec.timeouts不设会 fallback 到集群默认值 - 参数传递别用
spec.params硬塞字符串：Go 构造时应统一转为[]tektonpipelinev1.Param{{Name: "repo-url", Value: tektonpipelinev1.ParamValue{Type: "string", StringVal: "https://..."} }}，否则Type缺失会导致 Task 报invalid param type - 如果用 unstructured（比如对接自定义 CRD），必须显式调用
unstructured.SetGroupVersionKind(schema.GroupVersionKind{Group: "tekton.dev", Version: "v1", Kind: "PipelineRun"})，否则 controller 无法识别资源类型
Go 服务触发 PipelineRun 后如何可靠轮询状态
用 Go 触发流水线后，不能简单 sleep + get，得处理中断、超时、中间态跳变等真实场景。
- 用
clientset.TektonV1().PipelineRuns(namespace).Get(ctx, name, metav1.GetOptions{})获取最新状态，每次调用都应带新ctx（含 timeout），避免长连接 hang 住整个 goroutine - 关注
status.conditions数组而非仅status.phase：例如phase == "Running"但某 condition 的type == "Succeeded"且status == "False"，说明某个 Task 已失败，但 PipelineRun 还没来得及更新 phase - 轮询间隔建议从 1s 起步，5s 后指数退避（如 2s→4s→8s），避免对 apiserver 造成压力；Tekton controller 本身有 10s 状态刷新周期，太密无意义
- 务必检查
status.startTime和status.completionTime：若后者非空，无论 phase 是什么，都代表已终态；否则才需继续轮询
Go 编译的二进制在 Kubernetes 中调用 Tekton API 的权限问题
本地 go run 能通不代表部署到集群里也能通——ServiceAccount 权限缺失是静默失败的高发区。
立即学习“go语言免费学习笔记（深入）”；
- Pod 内 Go 程序默认用
defaultServiceAccount，它对tekton.devgroup 零权限；必须绑定ClusterRole（如tekton-pipelines-edit）或自建 Role，再通过RoleBinding绑定到对应 namespace - Go 代码中初始化 client 时，别用
rest.InClusterConfig()就完事：要加rest.SetKubernetesDefaults(config)，否则可能因 missing CA bundle 导致 TLS 握手失败，错误信息是x509: certificate signed by unknown authority - 若用
ServiceAccounttoken 访问，注意 token 默认挂载路径是/var/run/secrets/kubernetes.io/serviceaccount/token，Go 读取前应os.Stat确认存在，否则 client 初始化 panic - 权限最小化原则：不需要
delete就别给，尤其pipelineRuns/finalize权限一旦开放，可能被误删正在运行的流水线
真正麻烦的从来不是怎么写 Go 代码去调 Tekton，而是每个 PipelineRun 对象背后牵扯的 RBAC、namespace 隔离、condition 解析逻辑——这些地方一漏，日志里就只剩个 Unknown 状态，连该往哪查都不知道。
