云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载本文以 Tekton Pipeline本仓库对应 cloud-native Pipeline 资源实现的 API 演进为主线系统讲解从tekton.dev/v1beta1迁移到tekton.dev/v1时涉及的全部字段变更、废弃能力PipelineResources、ClusterTask、taskRef.bundle的替代方案以及PipelineRun中ServiceAccountName/PodTemplate向TaskRunTemplate的收敛。读完本文你将掌握 v1 与 v1beta1 实体的差异对照、可直接复制的 YAML 迁移示例并理解这些变更在控制器源码中的真实落地方式含timeouts计算、ResolverRef解析、版本转换逻辑从而平稳完成存量流水线的版本升级。一、为什么需要迁移v1 的定位与兼容机制在 Tekton Pipeline 的 API 演进中v1beta1是长期稳定使用的版本而v1是对 API 表面的一次系统性收敛移除废弃字段resources、cloudEvents、resourcesResult等、统一结果Result字段命名、用ResolverRef取代内嵌的bundle引用并把PipelineRun的公共运行配置收拢到TaskRunTemplate下。一个关键事实是v1beta1 与 v1 之间并不需要手工重写全部资源。仓库中为每个核心实体都实现了版本转换conversion逻辑例如 pipelinerun_conversion.go 中的ConvertTo/ConvertFrom负责把 v1beta1 的PipelineRun.Spec.Timeout转成 v1 的Timeouts.Pipeline见 pipelinerun_conversion.go#L72-L79把ServiceAccountName、PodTemplate迁入TaskRunTemplate见 pipelinerun_conversion.go#L80-L82。因此迁移工作的重点是理解新旧字段的对应关系、更新你手写的 YAML 清单、并针对被移除的能力如bundle、ClusterTask切换到新的 Resolver 方案。二、字段变更总表v1beta1 与 v1 对照以下表格完整罗列了 Tekton v1 中发生变更的字段以及对应的替代字段v1beta1 旧字段v1 新字段pipelineRun.spec.TimeoutpipelineRun.spec.timeouts.pipelinepipelineRun.spec.taskRunSpecs.taskServiceAccountNamepipelineRun.spec.taskRunSpecs.serviceAccountNamepipelineRun.spec.taskRunSpecs.taskPodTemplatepipelineRun.spec.taskRunSpecs.podTemplatetaskRun.status.taskResultstaskRun.status.resultspipelineRun.status.pipelineResultspipelineRun.status.resultstaskRun.spec.taskRef.bundletaskRun.spec.taskRef.resolverpipelineRun.spec.pipelineRef.bundlepipelineRun.spec.pipelineRef.resolvertask.spec.resources已从Task移除taskrun.spec.resources已从TaskRun移除taskRun.status.cloudEvents已从TaskRun移除taskRun.status.resourcesResult已从TaskRun移除pipeline.spec.resources已从Pipeline移除pipelineRun.spec.resources已从PipelineRun移除pipelineRun.spec.serviceAccountNamepipelineRun.spec.taskRunTemplate.serviceAccountNamepipelineRun.spec.podTemplatepipelineRun.spec.taskRunTemplate.podTemplatetask.spec.steps[].resourcestask.spec.steps[].computeResourcestask.spec.stepTemplate.resourcestask.spec.stepTemplate.computeResourcestask.spec.sidecars[].resourcestask.spec.sidecars[].computeResourcestaskRun.spec.sidecarOverridestaskRun.spec.sidecarSpecstaskRun.spec.stepOverridestaskRun.spec.stepSpecstaskRun.spec.sidecarSpecs[].resourcestaskRun.spec.sidecarSpecs[].computeResourcestaskRun.spec.stepSpecs[].resourcestaskRun.spec.stepSpecs[].computeResources这些变更可以从 v1 的类型定义中得到印证PipelineRunSpec中Timeouts *TimeoutFields、TaskRunTemplate PipelineTaskRunTemplate直接作为顶层字段存在且TimeoutFields由Pipeline、Tasks、Finally三部分构成见 pipelinerun_types.go#L277-L313PipelineRunStatusFields.Results []PipelineRunResult统一了结果字段命名见 pipelinerun_types.go#L534-L537TaskRunStatusFields.Results取代了旧的taskResults见 taskrun_types.go#L339-L342TaskRunSpec中的StepSpecs/SidecarSpecs取代了stepOverrides/sidecarOverrides且两者的覆盖项统一使用ComputeResources corev1.ResourceRequirements承载资源请求见 taskrun_types.go#L364-L378。三、把PipelineRun.Timeout升级为PipelineRun.Timeouts在 v1beta1 中PipelineRun.Spec.Timeout是一个单一的持续时间metav1.Duration只控制整个 PipelineRun 的总超时。v1 中它被PipelineRun.Spec.Timeouts取代一个对象内可以细粒度地分别设置三个超时字段含义timeouts.pipeline整个 Pipeline 执行的最大总时长对应旧timeout字段timeouts.tasksPipeline 中 tasks 部分的最大执行时长timeouts.finallyfinally 任务的最大执行时长约束关系为timeouts.pipeline timeouts.tasks timeouts.finally。该约束与默认值逻辑都写死在控制器侧PipelineRun.PipelineTimeout()、TasksTimeout()、FinallyTimeout()三个方法分别计算三档超时见 pipelinerun_types.go#L113-L157。其中TasksTimeout与FinallyTimeout在未显式设置时会尝试用pipeline减去另一项推算得出当某一档被设为永不超时NoTimeoutDuration时推算结果为空、视为无超时。迁移示例# 迁移前v1beta1 apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: pr-with-timeout spec: pipelineRef: name: example-pipeline timeout: 30m --- # 迁移后v1 apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pr-with-timeout spec: pipelineRef: name: example-pipeline timeouts: pipeline: 30m # 对应旧 timeout: 30m # tasks 与 finally 可按需补充如 tasks: 20m, finally: 5m如果你希望保持与旧行为完全等价只需把timeout的内容平移到timeouts.pipeline。在版本转换代码中这一对应关系也是自动完成的v1beta1 的prs.Timeout会被写入 v1 的sink.Timeouts.Pipeline见 pipelinerun_conversion.go#L76-L79。四、移除resources用 Workspaces 与 Task 替代 PipelineResourcesPipelineResources以及 Task、TaskRun、Pipeline、PipelineRun 上的resources字段已在 v1 中整体移除。迁移指引是改用Task表达输入输出例如通过 Workspaces 挂载卷、通过 Parameter / Result 传递数据替代原先以git、image、storage等 PipelineResource 类型描述的数据流。完整的替代思路可参考 pipelineresources.md。迁移时需要同步清理以下字段# 迁移前v1beta1中包含的字段v1 中不再存在 spec: resources: # task.spec.resources / pipeline.spec.resources 等 inputs: # task.spec.inputs.resources outputs: # task.spec.outputs.resources taskRun.spec.resources # TaskRun 侧的 resources pipelineRun.spec.resources从源码结构看v1 的TaskSpec、PipelineSpec类型中已经没有Resources字段v1beta1 的resource_types.gopkg/apis/pipeline/v1beta1/resource_types.go仍然保留PipelineResource相关类型仅用于历史兼容与转换而 v1 目录pkg/apis/pipeline/v1/下已不存在对应的 resource 类型文件。建议将原先依赖PipelineResource的场景迁移到 Workspaces参考 workspaces.md或直接以 Parameter/Result 传递数据。五、用 Bundle Resolver 替代taskRef.bundle与pipelineRef.bundle注意taskRef.bundle与pipelineRef.bundle目前已从 v1beta1 中移除本节内容仅为历史记录用途。如果旧清单通过bundle字段引用 OCI 镜像中的 Tekton 资源v1 中应改用远程解析Remote Resolution体系下的Bundle Resolver即把引用拆成resolver: bundles 一组params。使用该能力需要开启enable-bundles-resolver特性开关对应config-feature-flags.yaml中的enable-bundles-resolver配置安装与定制方式见 install.md。从 pkg/apis/config/resolver/feature_flags.go#L32-L46 可以看到enable-bundles-resolver与enable-cluster-resolver的默认值均为true即默认安装下该能力处于开启状态。# 迁移前v1beta1 apiVersion: tekton.dev/v1beta1 kind: TaskRun spec: taskRef: name: example-task bundle: python:3-alpine --- # 迁移后v1 apiVersion: tekton.dev/v1 kind: TaskRun spec: taskRef: resolver: bundles params: - name: bundle value: python:3-alpine - name: name value: taskName - name: kind value: Task对应地pipelineRef.bundle迁移为spec: pipelineRef: resolver: bundles params: - name: bundle value: your-oci-image:tag - name: name value: pipelineName - name: kind value: Pipelineresolver与params正是 v1 中ResolverRef结构体的两个字段Resolver ResolverName指明使用哪个解析器如git、bundles、clusterParams则承载解析所需的键值参数见 resolver_types.go。同时 v1 的TaskRef已内嵌ResolverRef并彻底移除bundle字段见 taskref_types.go#L19-L37。六、用 Cluster Resolver 替代 ClusterTaskClusterTask已被废弃v1 中请改用cluster resolver引用其他命名空间中的 Task / Pipeline。使用前需开启enable-cluster-resolver特性开关同样默认开启见 feature_flags.go#L34-L35。clusterresolver 允许Pipeline、PipelineRun、TaskRun引用集群中其他命名空间内定义的Pipeline和Task# 迁移前v1beta1 apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: cluster-task-reference spec: taskRef: name: example-task kind: ClusterTask --- # 迁移后v1 apiVersion: tekton.dev/v1 kind: TaskRun metadata: name: cluster-task-reference spec: taskRef: resolver: cluster params: - name: kind value: task - name: name value: example-task - name: namespace value: example-namespace要点kind参数取值为task小写name为要引用的资源名namespace为目标资源所在的命名空间引用 Pipeline 时将kind改为pipeline并把该段配置放在PipelineRun.Spec.PipelineRef下即可如需深入了解远程解析Remote Resolution的整体框架可阅读 resolution.md 与 how-to-write-a-resolver.md仓库中git、http、hub等 resolver 的实现位于 pkg/remoteresolution/resolver/。七、ServiceAccountName与PodTemplate迁入TaskRunTemplatev1 将PipelineRun.Spec顶层的ServiceAccountName与PodTemplate移动到了TaskRunTemplate中成为TaskRunTemplate.ServiceAccountName与TaskRunTemplate.PodTemplate。这样做的目的依据 TEP-119 中的注释是让用户可以把公共配置集中在TaskRunTemplate中一次性应用到该 PipelineRun 生成的所有 TaskRun无需逐个 TaskRun 重复指定。# 迁移前v1beta1 apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: template-pr spec: pipelineRef: name: clone-test-build serviceAccountName: build podTemplate: securityContext: fsGroup: 65532 --- # 迁移后v1 apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: template-pr spec: pipelineRef: name: clone-test-build taskRunTemplate: serviceAccountName: build podTemplate: securityContext: fsGroup: 65532迁移时请一并处理taskRunSpecs中的对应字段表 1 中已列出spec: taskRunSpecs: - pipelineTaskName: build # 旧字段 taskServiceAccountName / taskPodTemplate 已分别改为 serviceAccountName: build-sa podTemplate: securityContext: runAsUser: 1000需要说明的是podTemplate的语义在 v1 中保持不变仍为 Pod 级配置如securityContext、tolerations、nodeSelector等仅是位置发生了变化版本转换代码同样会自动完成该迁移prs.PodTemplate、prs.ServiceAccountName与sink.TaskRunTemplate相互映射见 pipelinerun_conversion.go#L80-L82 与 pipelinerun_conversion.go#L136-L143。八、迁移检查清单与最佳实践完成 v1beta1 → v1 迁移时建议按以下清单逐项核对API 版本所有清单的apiVersion从tekton.dev/v1beta1改为tekton.dev/v1。超时字段PipelineRun.spec.timeout→spec.timeouts.pipeline并按需补充tasks/finally。资源字段删除 Task / TaskRun / Pipeline / PipelineRun 上的一切resources字段改用 Workspaces 与 Parameter/Result 传递数据。结果字段消费方读取结果时改用taskRun.status.results与pipelineRun.status.results。Bundle 引用taskRef.bundle/pipelineRef.bundle→resolver: bundlesparams。ClusterTasktaskRef.kind: ClusterTask→resolver: clusterparams含namespace。公共配置PipelineRun.spec.serviceAccountName/podTemplate→taskRunTemplate.serviceAccountName/taskRunTemplate.podTemplatetaskRunSpecs中的taskServiceAccountName/taskPodTemplate→serviceAccountName/podTemplate。资源请求Step / Sidecar / StepTemplate 以及 TaskRun 的stepSpecs/sidecarSpecs中的resources→computeResources。覆盖字段stepOverrides→stepSpecssidecarOverrides→sidecarSpecs。迁移过程中的常见陷阱若你仍在使用 v1beta1 清单中的bundle字段集群侧会因该字段已被移除而拒绝创建该字段在 v1beta1 中也已废弃因此应尽早切换为 Bundle Resolvertimeouts.tasks timeouts.finally之和不能超过timeouts.pipeline否则校验失败computeResources遵循 Kubernetes 的ResourceRequirements语义requests/limits字段名与底层corev1.ResourceRequirements一一对应见 container_types.go#L80-L84。九、进一步阅读api-spec.mdv1 与各版本 API 的整体说明migrating-v1alpha1-to-v1beta1.md更早版本迁移的历史经验api-versioning.md版本演进与转换机制的开发者视角resolution.md远程解析Remote Resolution框架与各 Resolver 使用方式install.md特性开关如enable-bundles-resolver、enable-cluster-resolver的定制方法赞分享云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载相关推荐Tekton Pipeline 迁移指南从 v1alpha1.Run 到 v1beta1.CustomRunTekton Pipeline 迁移指南从 v1alpha1.Run 到 v1beta1.CustomRun 本文是 Tekton Pipelines当前仓云原生CI/CDDevOps后端Tekton Pipelines版本迁移路线图从v1alpha1到v1beta1再到v1平滑升级指南Tekton Pipelines版本迁移路线图从v1alpha1到v1beta1再到v1平滑升级指南 Tekton Pipelines 是一个面向云原生的流水云原生CI/CDDevOps后端golangci-lint v1 到 v2 配置迁移指南migrate 命令、字段变更与手动迁移清单golangci lint v1 到 v2 配置迁移指南migrate 命令、字段变更与手动迁移清单 导读 golangci lint v2 对配置文件的组织开发工具代码质量Lint静态分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考