云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载Tekton Plumbing 2020 Roadmap仓库内路径 vendor/github.com/tektoncd/plumbing/roadmap.md规划了 Tekton 社区基础设施团队在 2020 年的三大重点工作发布自动化Release Automation、基于 Tekton 的持续交付Tekton Based CD与基于 Tekton 的持续集成Tekton Based CI。其核心思想是Dogfooding——让 Tekton Pipelines 用自己的编排能力去构建、测试、发布 Tekton 自身。本文以这份路线图为骨架结合当前仓库tektoncd/pipeline中的真实实现发布流水线、夜间发布脚本、OCI Bundle 解析、云事件通知、e2e 测试体系还原这套自举式 CI/CD的完整图景帮助你理解 Tekton 社区如何组织发布流程、如何用 Pipeline 管理基础设施以及这些理念在当前代码库中沉淀成了哪些可复用的组件与工作流。一、路线图概览三大支柱路线图开篇即声明这是一份2020 年希望完成工作的不完整清单并提炼出三个重点方向方向目标当前仓库中的对应物Release Automation自动化发布、发布后验证hack/nightly.sh、tekton/release-pipeline.yaml、tekton/release-cheat-sheet.mdTekton Based CD用 Tekton 持续交付机器人、服务与基础设施tekton/release-pipeline.yaml、tekton/publish.yamlTekton Based CI用 Tekton 做持续集成Dogfoodingpkg/reconciler/events/、pkg/remote/oci/resolver.go、test/e2e-tests.sh三个方向层层递进先保证发布可靠再让交付与集成全部跑在 Tekton 自己身上最终达到基础设施本身也可移植、可被 CI 验证的目标。二、Release Automation从夜间发布到全自动发布2.1 夜间发布Nightly Releases路线图指出社区为 Pipeline、Triggers、Dashboard 三个组件分别做每晚发布nightly releases并把产物部署到 Robocat 集群再通过夜间测试验证发布质量对应 issue #288。当前仓库中的 hack/nightly.sh 正是这一机制的落地脚本其核心逻辑如下export KO_DOCKER_REPOgcr.io/tekton-nightly # Build the base image for git images. docker build -t ${KO_DOCKER_REPO}/github.com/tektoncd/pipeline/base -f images/Dockerfile images/ docker push ${KO_DOCKER_REPO}/github.com/tektoncd/pipeline/base要点解读KO_DOCKER_REPO指向gcr.io/tekton-nightly所有夜间构建产物统一推送到独立的 nightly 仓库与正式版stable发布到ghcr.io/tektoncd/pipeline隔离避免污染正式产物先构建base基础镜像git 类镜像需要统一的 base后续所有 pipeline 组件的夜间镜像都以它为底座保证一致性该脚本配合 CI 定时任务即可实现每晚自动发布 自动推送这正是路线图每晚发布的工程化表达。2.2 完整发布自动化触发即发布路线图对完整发布自动化提出三项明确要求触发发布无需访问基础设施集群——发布动作应通过可复现的流水线完成而不是人工登录集群操作自动生成发布说明release notes——从 git 历史、PR 提交中自动整理变更发布后的自动化集成测试——产物发布后立即在目标环境跑一遍集成测试。当前仓库把这三条要求全部落实在了Tekton 自身的发布流水线中即 tekton/release-pipeline.yaml。这份文件本身就是 Dogfooding 的绝佳例证发布 Pipeline 的编排完全由 Tekton 自身执行。该流水线的任务编排如下git-clone ──► precheck ──► unit-tests ─┐ └──► build ────┼──► publish-images ──► publish-to-bucket ──► report-bucket │ │ │ │ ▼ ▼ │ wait-for-chains prepare-draft-release │ │ │ └────────────┴──► create-draft-release关键设计亮点任务解析全部走远程解析器resolver例如git-clone通过bundles解析器从ghcr.io/tektoncd/catalog/upstream/tasks/git-clone:0.7拉取precheck、create-draft-release通过git解析器从tektoncd/plumbing仓库按固定 revision 拉取任务定义。这意味着触发发布不再需要预先在集群中维护一堆任务定义对应路线图触发发布无需访问基础设施集群的目标发布产物双通道输出publish-to-bucket将产物按repoName/previous/versionTag/归档publish-to-bucket-latest受releaseAsLatest参数控制默认 false同步到repoName/latest/两者都使用 Oracle Cloud Storage 上传任务版本标签统一管理versionTag参数区分两种格式——正式版vX.Y.Z与夜间版vYYYYMMDD-abc1234gitRevision指定要发布的 git 提交多架构构建buildPlatforms默认覆盖linux/amd64,linux/arm64,linux/s390x,linux/ppc64lepublishPlatforms额外加入windows/amd64Windows 镜像通过 base 镜像合并方案实现见 tekton/publish.yaml 中combine步骤签名与透明日志wait-for-chains任务等待 Tekton Chains 对publish-images的 TaskRun 完成签名再从 Rekorsigstore 透明日志中定位 in-toto 证明条目并提取rekor-uuid供发布说明引用——这正是供应链安全在发布环节的落地Draft Release 自动创建prepare-draft-release自动检测上一个版本标签按v前缀语义化排序create-draft-release生成 GitHub draft release。当github-secretworkspace 未绑定时这些任务会被自动跳过改由人工按 tekton/release-cheat-sheet.md 手动创建。2.3 发布操作手册从分支到发布tekton/release-cheat-sheet.md 是路线图发布自动化理念的操作化文档核心流程包括主/次版本发布从main分支选定提交创建release-vmajor.minor.x分支并推送Pipelines-as-CodePAC自动检测分支创建并触发.tekton/release.yaml版本号由分支名推导release-v1.10.x→v1.10.0补丁版本发布既可通过 GitHub Actions 的workflow_dispatch手动触发也可由每周四 10:00 UTC 的 cron 任务扫描活跃发布分支≥ v1.0自动触发发布后检查用如下命令验证发布产物是否可正常安装# 验证 latest 版本 kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml # 验证历史补丁版本 kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/previous/v1.10.1/release.yaml这两条命令直接对应路线图中发布后自动化集成测试的思路——产物落桶后立即在集群中安装验证补丁合入cherry-pick推荐使用 cherrypicker 插件在 PR 上评论/cherry-pick branch有冲突时按git fetch upstream branch→git checkout upstream/branch→git cherry-pick commit-hash手动处理发布命名遵循猫品种 著名机器人的模式如Devon Rex DreadnoughtLTS 版本加LTS后缀可用go run tekton/release_names.go生成。发布产物的最终形态由 tekton/publish.yaml 中的publish-releaseTask 生成通过ko resolve将 config/ 目录下的全部 CRD 与部署清单解析为release.yaml带 tag与release.notags.yaml供不支持image:tagdigest语法的运行时使用如 cri-o并把 YAML 中的devel占位版本号替换为实际versionTag。三、Tekton Based CD基础设施即 Pipeline路线图的第二部分是用 Tekton 做持续交付任务清单包括构建并发布机器人bots与服务servicesCD Tekton 资源——把 Tekton 各组件Pipeline、Triggers、Dashboard的部署本身交给 Pipeline 管理完全自动化的基础设施集群搭建——像 Robocat、prow、dogfooding 这样的集群其搭建过程应可一键复现去除定时任务中的样板代码对应 issue #262CDprow与dogfooding集群——不仅发布代码还要持续交付集群自身的配置。当前仓库中这一理念的集中体现正是上一节分析的 tekton/release-pipeline.yaml它同时扮演了三个角色——发布机器人自动完成镜像发布、产物归档、签名等待、draft release 创建替代了原先依赖人工的发布脚本Tekton 资源的 CD 管线publish-images直接引用 tekton/publish.yaml 生成可安装的release.yaml再通过publish-to-bucket归档用户kubectl apply该文件即完成对 Tekton 自身的持续交付基础设施配置即代码任务定义从tektoncd/plumbing仓库按固定 revision 解析precheck用50bc706c351cc05087564bb17afc1e658090edb0create-draft-release用ddcbc8eb56fe4b340ec4c0930f78e68b6a56783e确保基础设施代码与执行时刻都完全可复现这正是自动化搭建 infra-like 集群的基石。此外发布流水线的容错设计也体现了 CD 的工程素养即使 Chains 签名超时或找不到 TaskRun流水线也不会失败——因为产物已经发布draft release 可依据 cheat sheet 人工补建。这种发布产物优先、签名佐证兜底的策略保证了 CD 通道的高可用。四、Tekton Based CIDogfooding 的三条路径路线图第三部分对用 Tekton 做 CI给出了非常具体的清单当前仓库中每一小项都能找到对应实现。4.1 简化既有 CI云事件通知Simplify existing Tekton based CI with features from Pipeline and Triggers: Cloud events notifications, Task from OCI registries, Triggerable bundles?云事件通知CloudEvents是连接 Pipeline 与外部系统的关键能力。仓库在 pkg/reconciler/events/ 中实现了完整的事件体系分为pkg/reconciler/events/cloudevent/CloudEvent 的构造、发送与重试逻辑pkg/reconciler/events/k8sevent/Kubernetes 原生 Event 的生成。行为细节记录在 docs/events.md 中通过 config/config-defaults.yaml 等配置控制事件发送策略TaskRun/PipelineRun的生命周期开始、成功、失败、超时、取消均可触发事件。CI 系统收到 CloudEvent 后即可驱动下游动作如更新 job 状态、触发通知这正是更新日志应用以支持 CI 需求与构建 job 运行追踪路线图中提到的 GitHub App / 自有方案 / testgrid 候选的前置条件。Task from OCI registriesOCI Bundle是让 CI 任务像镜像一样可分发的实现。仓库在 pkg/remote/oci/resolver.go 实现了从 OCI 仓库拉取 Task/Pipeline 定义的解析器配套的框架代码位于 pkg/remoteresolution/。前面提到的发布流水线本身就是它的大规模用户——git-clone、golang-test、golang-build、oracle-cloud-storage-upload等任务全部以bundles解析器从 catalog 拉取例如taskRef: resolver: bundles params: - name: bundle value: ghcr.io/tektoncd/catalog/upstream/tasks/git-clone:0.7 - name: name value: git-clone - name: kind value: task这意味着定义新 CI job 时只需在流水线中声明resolver: bundles bundle 地址任务即可按需加载无需预先安装——完全回应了路线图让定义新 CI job 变简单的目标。4.2 用 Tekton 实现 CI job 并测试基础设施路线图计划用 Tekton 实现一批 CI job对应 issue #291、#288、#286、#283并在 CI 中测试基础设施变更、支持可移植测试与多云测试。当前仓库的 e2e 体系是这一方向的执行层。以 test/e2e-tests.sh 为例它已经参数化出多种feature gate组合PIPELINE_FEATURE_GATE${PIPELINE_FEATURE_GATE:-stable} SKIP_INITIALIZE${SKIP_INITIALIZE:false} E2E_GO_TEST_TIMEOUT${E2E_GO_TEST_TIMEOUT:20m} ENABLE_CEL_IN_WHENEXPRESSION${ENABLE_CEL_IN_WHENEXPRESSION:false} ENABLE_ARTIFACTS${ENABLE_ARTIFACTS:false}脚本通过set_feature_gate把enable-api-fields打补丁到feature-flagsConfigMapstable/beta/alpha三档并可开启 CEL 表达式、Artifacts、Kubernetes Sidecar、终止消息压缩等实验性特性。仓库根目录还配套了多套环境模板test/e2e-tests-kind-stable.env、test/e2e-tests-kind-alpha.env、test/e2e-tests-kind-beta.env 等用同一套测试代码覆盖不同的特性组合——这正是在 CI 中测试基础设施变更在不同云/不同配置上测试的可移植测试雏形。从源码结构看test/ 目录下的*_test.go如 test/pipelinerun_test.go、test/workspace_test.go全部基于真实 Kubernetes 集群运行而 DEVELOPMENT.md 给出了本地复现路径ko apply -R -f config/安装到 kind 集群后执行go test -v -count1 -tagse2e -timeout20m ./test。这套本地 kind e2e 测试的工作流正是路线图测试基础设施变更在 CI 中进行的日常化操作。4.3 基础设施可移植性Make Tekton infra portable (e.g. GitLab or others) — Reduce GitHub specific solution路线图最后强调Tekton 的基础设施不能绑定单一代码托管平台GitHub应当可移植到 GitLab 等平台。这与第一、二节形成闭环——发布/CI 流程以 Tekton Pipeline 定义YAML承载而非平台专属的 CI 配置因此只要目标平台能运行 Tekton整套 CI/CD 就能搬过去。当前仓库将发布任务定义沉淀在tektoncd/plumbing仓库并以固定 revision 引用见 tekton/release-pipeline.yaml 的precheck、create-draft-release任务从实现层面把基础设施代码与托管平台解耦是可移植性方向的直接证据。五、路线图的落地启示回看这份 2020 年路线图再对照当前仓库可以总结出几条对自建 CI/CD 平台有直接借鉴价值的结论自举Dogfooding是质量的最佳保障Tekton 的发布、签名、归档、draft release 全流程都跑在自己的 Pipeline 上tekton/release-pipeline.yaml每次发布同时就是一次产品级压力测试任务定义远程化是自动化发布的前提bundles/git解析器pkg/remote/oci/resolver.go、pkg/remoteresolution/让触发发布不需要访问基础设施集群成为可能夜间发布 发布后测试构成质量双保险hack/nightly.sh 提供高频反馈tekton/release-cheat-sheet.md 的kubectl apply验证命令提供发布后集成测试事件驱动让 CI 生态可扩展云事件通知pkg/reconciler/events/把 Pipeline 状态变化开放给外部系统是连接CI job 追踪通知机器人等周边服务的标准接口基础设施代码可移植将任务定义、集群配置全部沉淀为仓库中的 YAML 并固定 revision 引用使整套 CI/CD 摆脱对单一平台的依赖。对于希望参考 Tekton 组织自身工程实践的团队建议从 tekton/release-pipeline.yaml 与 tekton/release-cheat-sheet.md 入手前者是用平台编排平台的完整范本后者是发布流程的运维手册两者结合即可复现 Tekton 社区这套从夜间发布、签名验证到 draft release 的全自动发布链路。赞分享云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载相关推荐Tekton Pipelines 的自举式发布用 Tekton 构建、测试与发布 Tektontekton/ 目录 CI/CD 全解析Tekton Pipelines 的自举式发布用 Tekton 构建、测试与发布 Tektontekton/ 目录 CI/CD 全解析 本指南围绕当前仓库云原生CI/CDDevOps后端30分钟上手Tekton Pipeline从0到1构建自动化任务流30分钟上手Tekton Pipeline从0到1构建自动化任务流 为什么选择Tekton Pipeline 在云原生时代Kubernetes已成为容器编云原生CI/CDDevOps后端Tekton Pipeline 的 Tekton Bundle Contract 详解OCI 镜像中 Task/Pipeline 的分发契约与实现验证Tekton Pipeline 的 Tekton Bundle Contract 详解OCI 镜像中 Task/Pipeline 的分发契约与实现验证 本指南云原生CI/CDDevOps后端上一篇微信聊天记录导出教程用WeChatMsg永久保存记录免费生成年度报告下一篇KMS_VL_ALL_AIO5分钟跑通本地KMS激活教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考