Renovate Tekton Manager 深度解析自动更新 Tekton Bundle 引用、PipelinesAsCode 远程资源与 Task 容器镜像【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 内置的tektonmanager 专门负责扫描 Kubernetes 集群中 Tekton 相关的 YAML 资源Task、Pipeline、TaskRun、PipelineRun 等自动追踪并更新三类依赖Tekton Bundle 的 OCI 镜像引用、PipelinesAsCode 远程 HTTP URL 引用基于 Git tag 或 GitHub Release 的版本化资源以及 Task 内各 step/sidecar/stepTemplate 中配置的容器镜像。读完后你将理解如何为tektonmanager 正确配置managerFilePatterns、哪些 Tekton 资源字段会被提取为依赖以及 Renovate 在源码层面如何解析 Bundle resolver、PipelinesAsCode 注解与镜像引用。Tekton 与资源分发方式manager 的关注点Tekton 是一个开源的云原生 CI/CD 解决方案它用Task封装要执行的具体命令用Pipeline组合多个 Task 来完成构建容器镜像这类目标Task 和 Pipeline 都以 Kubernetes 自定义资源Custom Resource的形式定义。Task 和 Pipeline 定义有两大类分发方式直接作为集群内资源创建用kubectl等标准工具把 Task/Pipeline 直接 apply 到集群中资源引用Resource Reference分发定义存放在集群之外Tekton 在运行时按需拉取。这种方式只保存一个引用URL 或 OCI Bundle 地址而非完整定义。Renovate 的tektonmanager 聚焦于第二类场景——对 Tekton 资源引用本身提供版本更新。这一点也解释了它的depType设计从 dep-types.ts 可以看到 manager 定义了三类依赖元数据depType含义tekton-annotation通过注解引用的 Tekton 资源如 GitHub Release 或 Git tag 形式的 URLtekton-bundleTekton Bundle 的 OCI 镜像引用tekton-step-imageTekton step、sidecar 或 step template 中使用的容器镜像支持的引用方式总览当前tektonmanager 支持的远程引用包括Tekton Bundle以 OCI 镜像形式分发的 Task/Pipeline 目录包PipelinesAsCode 远程 HTTP URL 引用指向 raw Git 资源或 GitHub Release 下载链接的 URL配合 Git 版本化tag使用。PipelinesAsCode 远程 URL 注解用法在 PipelineRun或 TaskRun的metadata.annotations中通过pipelinesascode.tekton.dev/task与pipelinesascode.tekton.dev/pipeline两个注解指定远程 Task / Pipeline。一个典型的pipeline-run.yaml如下apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: main annotations: pipelinesascode.tekton.dev/task: https://github.com/foo/bar/raw/v0.0.1/task/my-task/my-task.yaml pipelinesascode.tekton.dev/pipeline: https://github.com/foo/bar/raw/v0.0.1/pipeline/my-pipeline/my-pipeline.yamlmanager 可识别的 URL 形态有三种源码中的正则与之一一对应https://github.com/foo/bar/raw/v0.0.1/tasks/task/task.yamlGitHub 的raw短路径https://raw.githubusercontent.com/foo/bar/v0.0.1/tasks/task/task.yamlraw.githubusercontent 域名https://github.com/foo/bar/releases/download/v0.0.1/create-git-tag-task.yamlGitHub Release 资产下载源码视角注解如何被解析为依赖解析逻辑位于 extract.ts几个关键点值得展开注解键的正则匹配。annotationRegex定义为/^pipelinesascode\.tekton\.dev\/(?:task(?:-[0-9])?|pipeline)$/即只匹配.../task、.../pipeline以及.../task-N多 Task 场景下 PipelinesAsCode 使用的编号后缀。on-event这类其他注解会被直接忽略。值可以是逗号分隔的列表。源码会先剥离首尾的[与]再按逗号split逐一提取 URL——这与测试夹具 multi-doc-annotations.yaml 中[git-clone, https://github.com/foo/bar/releases/download/v0.0.4/...]这种内置 Task 与远程 URL 混排的注解写法相互印证。URL → 数据源的映射。getAnnotationDep()依次尝试两条正则githubRelease匹配/releases/download/version/...路径命中后datasource设为github-releasesdepName为仓库路径如github.com/foo/barcurrentValue为版本号如v0.0.4gitUrl匹配/raw/.../tag/...或raw.githubusercontent.com/owner/repo/tag/...路径命中后datasource设为git-tags。源码还会把raw.githubusercontent.com统一替换为github.com再填入depName保证依赖名与 Renovate 中 GitHub 仓库的命名一致。不可识别的 URL 直接跳过返回null不会产生伪依赖。从 extract.spec.ts 的断言可以看到https://raw.githubusercontent.com/foo/baz/v0.0.12/pipeline/deploy/deploy.yaml会被解析为depName: github.com/foo/baz、packageName: https://github.com/foo/baz、currentValue: v0.0.12的git-tags依赖——这意味着 Renovate 会用git-tags数据源去仓库里查最新的 tag并自动改写注解 URL 中的版本片段。Tekton Bundle 引用的三种写法使用 Bundle 引用有等价的三条路径Renovate 的tektonmanager全部支持通过Tekton Bundles Resolverresolver: bundlesparams通过tektoncd/resolution项目的 resolver 声明通过旧式属性taskRun.spec.taskRef.bundle与pipelineRun.spec.pipelineRef.bundle。优先级逻辑在 extract.ts 的addDep()中清晰可见// 1. 优先走 Bundle resolverresolver bundles 时从 params 里取 name bundle 的 value if (ref.resolver bundles) { imageRef getBundleValue(ref.params); if (isNullOrUndefined(imageRef)) { // 2. 回退到已废弃的 resource 属性 imageRef getBundleValue(ref.resource); } } // 3. 再回退到旧式 bundle 字段 if (isNullOrUndefined(imageRef)) { imageRef ref.bundle; }这段实现与夹具 multi-doc.yaml 中的注释完全对应pipeline任务直接写bundle:字段finally任务同时写了bundle: .../ignored:1.0和resolver: bundlesparams最终被提取的是 params 中的gcr.io/tekton-releases/catalog/upstream/pipeline-finally:1.0——即Bundle resolver 的params.bundle优先于废弃的bundle字段pipeline-run-resolver则演示了params中无 bundle 时回退到废弃的resource属性的路径。Bundle 镜像引用最终交给getDep()复用自 dockerfile/extract.ts 的 Docker 镜像解析器拆解出depName、currentValuetag与currentDigestsha256:...摘要因此 Bundle 既可跟随 tag 升级也可做 digest 更新。Task 容器镜像的提取范围除了远程引用manager 还会把 Tekton 运行 Task 时使用的容器镜像识别为tekton-step-image依赖。支持范围如下镜像可配置的位置见 extract.ts 的addStepImageSpec()Task 的steps[].imageTask 的stepTemplate.imageTask 的sidecars[].image。承载 Task 定义的资源类型getDeps()的逐段处理逻辑Task直接遍历spec.stepsTaskRun处理spec.taskRefBundle 引用与内联的spec.taskSpecPipeline遍历spec.tasks与spec.finally数组中每个元素的taskRef/taskSpecPipelineRun处理spec.pipelineRefBundle 引用与内联的spec.pipelineSpec会递归走同一套提取逻辑;StepAction读取spec.imageaddStepActionImage()。此外还有两个容易被忽略的入口TriggerTemplate的spec.resourcetemplates数组对每个模板递归提取以及kind: List资源的items数组——multi-doc.yaml 中同时演示了这两种嵌套形态。对应的结构化类型定义见 types.ts其中TektonResourceSpec把上述各字段的适用资源以注释标明TektonBundle则定义了bundle/resolver/params/resource四个字段。一个完整的提取结果示例来自 extract.spec.ts 对夹具的断言{ depName: gcr.io/tekton-releases/catalog/upstream/pipeline, currentValue: 1.0, currentDigest: sha256:01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b, datasource: docker, depType: tekton-bundle, }值得注意的边界行为无法解析的 Bundle 值如夹具中bundle: true会被标记为skipReason: invalid-value而不是崩溃空文件、纯标量 YAML如foo: bar直接返回null文件被视为无依赖而不进入更新流程多文档---分隔YAML 会逐文档遍历提取因此一个pipeline-run.yaml里堆叠多个资源也没问题。启用方式managerFilePatterns必须自行配置tektonmanager没有默认的managerFilePatterns——在 index.ts 中可以看到export const defaultConfig { managerFilePatterns: [], };这是有意为之Tekton 资源没有约定俗成的文件名模式不像.github/workflows/*.yml之于 GitHub Actions如果默认匹配所有 YAML会把大量无关文件卷入解析。因此你必须显式配置匹配规则后才会有文件被扫描。例如让仓库中所有 YAML 文件都参与 Tekton 依赖提取{ tekton: { managerFilePatterns: [/\\.yaml$/, /\\.yml$/] } }也可以收窄到 CI 目录减少误匹配面{ tekton: { managerFilePatterns: [/tekton/.*\\.ya?ml$/, /\\.gitlab-ci\\.ya?ml$/] } }managerFilePatterns中的每一项都是正则字符串与仓库内文件的相对路径做匹配。数据源与版本规则从 index.ts 的supportedDatasources声明可知tektonmanager 依赖两个数据源数据源用途dockerBundle OCI 镜像引用、step/sidecar/stepTemplate 容器镜像的 tag 与 digest 更新git-tagsPipelinesAsCode 注解中指向 Git 仓库 raw 资源的版本引用注解中的 GitHub Release 下载 URL 则走github-releases数据源见getAnnotationDep()的实现。镜像类依赖默认采用 docker 版本规则git-tags类引用则走 git 版本规则如需调整例如 Bundle tag 不含v前缀可按需在 Renovate 配置中为对应depType指定versioning。仓库中可用的版本规则实现位于 lib/modules/versioning/ 目录如semver、docker、git等子目录可对照挑选与你的资源版本风格一致的规则。小结Renovate 的tektonmanager 覆盖了 Tekton 资源引用的三种主流分发形态Bundle resolver 参数式引用、旧式bundle属性引用以及 PipelinesAsCode 的远程 HTTP URL 注解含 Git raw 与 GitHub Release 两类 URL外加 Task 全场景step、stepTemplate、sidecar跨 Task/TaskRun/Pipeline/PipelineRun/StepAction的容器镜像更新。启用前请务必记住它的零默认匹配设计先配置managerFilePatterns这个 manager 才会开始工作。相关实现与测试集中在 lib/modules/manager/tekton/ 目录是进一步理解其提取细节的最佳入口。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Renovate Tekton Manager 深度解析：自动更新 Tekton Bundle 引用、PipelinesAsCode 远程资源与 Task 容器镜像
Renovate Tekton Manager 深度解析自动更新 Tekton Bundle 引用、PipelinesAsCode 远程资源与 Task 容器镜像【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 内置的tektonmanager 专门负责扫描 Kubernetes 集群中 Tekton 相关的 YAML 资源Task、Pipeline、TaskRun、PipelineRun 等自动追踪并更新三类依赖Tekton Bundle 的 OCI 镜像引用、PipelinesAsCode 远程 HTTP URL 引用基于 Git tag 或 GitHub Release 的版本化资源以及 Task 内各 step/sidecar/stepTemplate 中配置的容器镜像。读完后你将理解如何为tektonmanager 正确配置managerFilePatterns、哪些 Tekton 资源字段会被提取为依赖以及 Renovate 在源码层面如何解析 Bundle resolver、PipelinesAsCode 注解与镜像引用。Tekton 与资源分发方式manager 的关注点Tekton 是一个开源的云原生 CI/CD 解决方案它用Task封装要执行的具体命令用Pipeline组合多个 Task 来完成构建容器镜像这类目标Task 和 Pipeline 都以 Kubernetes 自定义资源Custom Resource的形式定义。Task 和 Pipeline 定义有两大类分发方式直接作为集群内资源创建用kubectl等标准工具把 Task/Pipeline 直接 apply 到集群中资源引用Resource Reference分发定义存放在集群之外Tekton 在运行时按需拉取。这种方式只保存一个引用URL 或 OCI Bundle 地址而非完整定义。Renovate 的tektonmanager 聚焦于第二类场景——对 Tekton 资源引用本身提供版本更新。这一点也解释了它的depType设计从 dep-types.ts 可以看到 manager 定义了三类依赖元数据depType含义tekton-annotation通过注解引用的 Tekton 资源如 GitHub Release 或 Git tag 形式的 URLtekton-bundleTekton Bundle 的 OCI 镜像引用tekton-step-imageTekton step、sidecar 或 step template 中使用的容器镜像支持的引用方式总览当前tektonmanager 支持的远程引用包括Tekton Bundle以 OCI 镜像形式分发的 Task/Pipeline 目录包PipelinesAsCode 远程 HTTP URL 引用指向 raw Git 资源或 GitHub Release 下载链接的 URL配合 Git 版本化tag使用。PipelinesAsCode 远程 URL 注解用法在 PipelineRun或 TaskRun的metadata.annotations中通过pipelinesascode.tekton.dev/task与pipelinesascode.tekton.dev/pipeline两个注解指定远程 Task / Pipeline。一个典型的pipeline-run.yaml如下apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: main annotations: pipelinesascode.tekton.dev/task: https://github.com/foo/bar/raw/v0.0.1/task/my-task/my-task.yaml pipelinesascode.tekton.dev/pipeline: https://github.com/foo/bar/raw/v0.0.1/pipeline/my-pipeline/my-pipeline.yamlmanager 可识别的 URL 形态有三种源码中的正则与之一一对应https://github.com/foo/bar/raw/v0.0.1/tasks/task/task.yamlGitHub 的raw短路径https://raw.githubusercontent.com/foo/bar/v0.0.1/tasks/task/task.yamlraw.githubusercontent 域名https://github.com/foo/bar/releases/download/v0.0.1/create-git-tag-task.yamlGitHub Release 资产下载源码视角注解如何被解析为依赖解析逻辑位于 extract.ts几个关键点值得展开注解键的正则匹配。annotationRegex定义为/^pipelinesascode\.tekton\.dev\/(?:task(?:-[0-9])?|pipeline)$/即只匹配.../task、.../pipeline以及.../task-N多 Task 场景下 PipelinesAsCode 使用的编号后缀。on-event这类其他注解会被直接忽略。值可以是逗号分隔的列表。源码会先剥离首尾的[与]再按逗号split逐一提取 URL——这与测试夹具 multi-doc-annotations.yaml 中[git-clone, https://github.com/foo/bar/releases/download/v0.0.4/...]这种内置 Task 与远程 URL 混排的注解写法相互印证。URL → 数据源的映射。getAnnotationDep()依次尝试两条正则githubRelease匹配/releases/download/version/...路径命中后datasource设为github-releasesdepName为仓库路径如github.com/foo/barcurrentValue为版本号如v0.0.4gitUrl匹配/raw/.../tag/...或raw.githubusercontent.com/owner/repo/tag/...路径命中后datasource设为git-tags。源码还会把raw.githubusercontent.com统一替换为github.com再填入depName保证依赖名与 Renovate 中 GitHub 仓库的命名一致。不可识别的 URL 直接跳过返回null不会产生伪依赖。从 extract.spec.ts 的断言可以看到https://raw.githubusercontent.com/foo/baz/v0.0.12/pipeline/deploy/deploy.yaml会被解析为depName: github.com/foo/baz、packageName: https://github.com/foo/baz、currentValue: v0.0.12的git-tags依赖——这意味着 Renovate 会用git-tags数据源去仓库里查最新的 tag并自动改写注解 URL 中的版本片段。Tekton Bundle 引用的三种写法使用 Bundle 引用有等价的三条路径Renovate 的tektonmanager全部支持通过Tekton Bundles Resolverresolver: bundlesparams通过tektoncd/resolution项目的 resolver 声明通过旧式属性taskRun.spec.taskRef.bundle与pipelineRun.spec.pipelineRef.bundle。优先级逻辑在 extract.ts 的addDep()中清晰可见// 1. 优先走 Bundle resolverresolver bundles 时从 params 里取 name bundle 的 value if (ref.resolver bundles) { imageRef getBundleValue(ref.params); if (isNullOrUndefined(imageRef)) { // 2. 回退到已废弃的 resource 属性 imageRef getBundleValue(ref.resource); } } // 3. 再回退到旧式 bundle 字段 if (isNullOrUndefined(imageRef)) { imageRef ref.bundle; }这段实现与夹具 multi-doc.yaml 中的注释完全对应pipeline任务直接写bundle:字段finally任务同时写了bundle: .../ignored:1.0和resolver: bundlesparams最终被提取的是 params 中的gcr.io/tekton-releases/catalog/upstream/pipeline-finally:1.0——即Bundle resolver 的params.bundle优先于废弃的bundle字段pipeline-run-resolver则演示了params中无 bundle 时回退到废弃的resource属性的路径。Bundle 镜像引用最终交给getDep()复用自 dockerfile/extract.ts 的 Docker 镜像解析器拆解出depName、currentValuetag与currentDigestsha256:...摘要因此 Bundle 既可跟随 tag 升级也可做 digest 更新。Task 容器镜像的提取范围除了远程引用manager 还会把 Tekton 运行 Task 时使用的容器镜像识别为tekton-step-image依赖。支持范围如下镜像可配置的位置见 extract.ts 的addStepImageSpec()Task 的steps[].imageTask 的stepTemplate.imageTask 的sidecars[].image。承载 Task 定义的资源类型getDeps()的逐段处理逻辑Task直接遍历spec.stepsTaskRun处理spec.taskRefBundle 引用与内联的spec.taskSpecPipeline遍历spec.tasks与spec.finally数组中每个元素的taskRef/taskSpecPipelineRun处理spec.pipelineRefBundle 引用与内联的spec.pipelineSpec会递归走同一套提取逻辑;StepAction读取spec.imageaddStepActionImage()。此外还有两个容易被忽略的入口TriggerTemplate的spec.resourcetemplates数组对每个模板递归提取以及kind: List资源的items数组——multi-doc.yaml 中同时演示了这两种嵌套形态。对应的结构化类型定义见 types.ts其中TektonResourceSpec把上述各字段的适用资源以注释标明TektonBundle则定义了bundle/resolver/params/resource四个字段。一个完整的提取结果示例来自 extract.spec.ts 对夹具的断言{ depName: gcr.io/tekton-releases/catalog/upstream/pipeline, currentValue: 1.0, currentDigest: sha256:01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b, datasource: docker, depType: tekton-bundle, }值得注意的边界行为无法解析的 Bundle 值如夹具中bundle: true会被标记为skipReason: invalid-value而不是崩溃空文件、纯标量 YAML如foo: bar直接返回null文件被视为无依赖而不进入更新流程多文档---分隔YAML 会逐文档遍历提取因此一个pipeline-run.yaml里堆叠多个资源也没问题。启用方式managerFilePatterns必须自行配置tektonmanager没有默认的managerFilePatterns——在 index.ts 中可以看到export const defaultConfig { managerFilePatterns: [], };这是有意为之Tekton 资源没有约定俗成的文件名模式不像.github/workflows/*.yml之于 GitHub Actions如果默认匹配所有 YAML会把大量无关文件卷入解析。因此你必须显式配置匹配规则后才会有文件被扫描。例如让仓库中所有 YAML 文件都参与 Tekton 依赖提取{ tekton: { managerFilePatterns: [/\\.yaml$/, /\\.yml$/] } }也可以收窄到 CI 目录减少误匹配面{ tekton: { managerFilePatterns: [/tekton/.*\\.ya?ml$/, /\\.gitlab-ci\\.ya?ml$/] } }managerFilePatterns中的每一项都是正则字符串与仓库内文件的相对路径做匹配。数据源与版本规则从 index.ts 的supportedDatasources声明可知tektonmanager 依赖两个数据源数据源用途dockerBundle OCI 镜像引用、step/sidecar/stepTemplate 容器镜像的 tag 与 digest 更新git-tagsPipelinesAsCode 注解中指向 Git 仓库 raw 资源的版本引用注解中的 GitHub Release 下载 URL 则走github-releases数据源见getAnnotationDep()的实现。镜像类依赖默认采用 docker 版本规则git-tags类引用则走 git 版本规则如需调整例如 Bundle tag 不含v前缀可按需在 Renovate 配置中为对应depType指定versioning。仓库中可用的版本规则实现位于 lib/modules/versioning/ 目录如semver、docker、git等子目录可对照挑选与你的资源版本风格一致的规则。小结Renovate 的tektonmanager 覆盖了 Tekton 资源引用的三种主流分发形态Bundle resolver 参数式引用、旧式bundle属性引用以及 PipelinesAsCode 的远程 HTTP URL 注解含 Git raw 与 GitHub Release 两类 URL外加 Task 全场景step、stepTemplate、sidecar跨 Task/TaskRun/Pipeline/PipelineRun/StepAction的容器镜像更新。启用前请务必记住它的零默认匹配设计先配置managerFilePatterns这个 manager 才会开始工作。相关实现与测试集中在 lib/modules/manager/tekton/ 目录是进一步理解其提取细节的最佳入口。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考