云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载本篇速查表面向 Tekton Pipelines 的发布管理者release manager系统梳理该项目基于 Pipelines-as-CodePAC的自动化发布机制如何通过创建release-vX.Y.x分支触发 initial releasemajor/minor、如何通过手动或 cron 触发 patch release、发布完成后的收尾步骤、补丁 cherry-pick 流程、命名规范与基础设施清单。读者读完后将具备独立完成一次 Tekton Pipelines 官方版本发布、验收并发布 GitHub draft release 的完整实操能力并理解背后tekton/与.tekton/目录中的真实发布管线实现。总体流程概览Tekton Pipelines 采用用 Tekton 发布 Tekton的 dogfooding 实践tekton/目录存放发布用的 Pipeline 与 Task 定义.tekton/目录存放由 Pipelines-as-Code 触发的 PipelineRun 模板。发布管线运行在共享的 Tekton 基础设施集群上整个流程可归纳为创建 release-vX.Y.x 分支 / 触发 patch workflow │ ▼ PAC 检测事件 → 启动 PipelineRun.tekton/release*.yaml │ ▼ tekton/release-pipeline.yaml 执行clone → precheck → 测试/构建 → 发布镜像 → 上传 bucket → Chains 签名 → 创建 draft release │ ▼ 人工验收 draft GitHub release → 发布 │ ▼ Post-release 步骤更新 README/releases.md、集群实测、Slack 通告、plumbing/website 更新后续各节将逐一展开每一环节的细节并在相应位置结合 tekton/release-pipeline.yaml、tekton/publish.yaml、.tekton/release.yaml 与 .tekton/release-patch.yaml 等仓库文件说明底层实现。自动化发布机制Pipelines-as-Code官方发布完全由Pipelines-as-CodePAC驱动。PAC 监听 GitHub 仓库事件自动在共享 Tekton 基础设施集群上创建并执行 PipelineRun。发布用的事件模板位于仓库根目录的.tekton/目录实际执行的 Pipeline 定义位于 tekton/release-pipeline.yaml。从 .tekton/release.yaml 可以看到 initial release 的触发条件pipelinesascode.tekton.dev/on-event: [push] pipelinesascode.tekton.dev/on-target-branch: [refs/heads/release-v*] pipelinesascode.tekton.dev/on-cel-expression: | event push has(body.created) body.created true target_branch.startsWith(release-v) pipelinesascode.tekton.dev/pipeline: tekton/release-pipeline.yaml pipelinesascode.tekton.dev/max-keep-runs: 5这段注解annotation明确了两层过滤on-event/on-target-branch只关注推送到release-v*分支的 push 事件on-cel-expression进一步要求该分支是本次新建的body.created true从而避免已有的 release 分支上后续的普通推送反复触发发布。文件注释还特别提醒on-cel-expression优先级高于on-event/on-target-branch因此分支过滤条件必须写进 CEL 表达式。类似地.tekton/release-patch.yaml 面向 patch release其触发方式是on-event: [incoming]即通过 PAC 的 incoming webhook 传入动态参数版本号{{ version }}、release_as_latest等适用于下面的手动与 cron 两种触发路径。Initial Releasemajor/minor 版本发布第一步挑选提交并创建 release 分支在main分支上选定要用于构建发布的 commit然后从该 commit 创建并推送 release 分支git checkout -b release-v1.10.x commit-sha git push upstream release-v1.10.x其中upstream指向tektoncd/pipeline官方仓库下文的 cherry-pick 与手动补丁流程同样使用该 remote 约定。第二步PAC 自动触发与版本推导分支创建并推送后PAC 自动检测到新建 release 分支事件触发 .tekton/release.yaml 中定义的 PipelineRun进而执行 tekton/release-pipeline.yaml 中的pipeline-releasePipeline。版本号完全由分支名推导见.tekton/release.yaml中的 CEL 表达式- name: versionTag value: {{ cel: pac.target_branch.replace(release-, ).replace(.x, .0) }}即release-v1.10.x→v1.10.0。这一推导逻辑与tekton/目录中release-pipeline.yaml的versionTag参数定义相互印证——参数描述明确写道 Version tag (vX.Y.Z for stable, vYYYYMMDD-abc1234 for nightly)。第三步监控 PipelineRun发布过程通常需要数小时发布管理者通过以下方式实时监控Tekton Dashboard访问 https://tekton.infra.tekton.dev/#/namespaces/releases-pipeline/pipelineruns 查看releases-pipeline命名空间下的 PipelineRun命令行日志tkn pac logs -n releases-pipeline -L直接跟随输出最新一次运行的日志。第四步验收并发布 draft GitHub release管线成功完成后会自动创建一个draft草稿GitHub release。发布管理者需要人工完成以下验收步骤手动补充upgrade升级与 deprecation弃用说明核对提交列表是否与预期一致取消勾选 This is a pre-release正式发布不应标记为预发布点击Publish release正式发布。这一draft 自动创建、人工确认发布的设计把机械工作交给自动化把质量把关留在人侧。draft 创建依赖github-secretworkspace 中绑定的 GITHUB_TOKEN若未绑定管线会跳过 draft 相关任务wait-for-chains、prepare-draft-release、create-draft-release需按速查表手动创建 draft见 tekton/release-pipeline.yaml 中github-secret的说明。Patch Releasebugfix 补丁发布Patch release 支持手动触发与**自动触发每周 cron**两种方式两者最终都通过 PAC incoming webhook 进入 .tekton/release-patch.yaml 定义的 PipelineRun。手动触发workflow_dispatch打开 GitHub 仓库的Actions → Patch Release工作流对应patch-release.yamlworkflow点击Run workflow填写参数release branch如release-v1.10.xversion如v1.10.1遵循 semver 的补丁版本号递增规则Publish as latest release按需设置是否将本次补丁标记为最新版本再次点击Run workflow确认。该 workflow 通过 PAC incoming webhook 触发发布管线即.tekton/release-patch.yaml中的on-event: [incoming]事件version与release_as_latest等参数由 webhook payload 动态传入。自动触发每周 cron一个 cron 任务每周四 10:00 UTC运行扫描所有活跃的 release 分支≥ v1.0上自上一个 tag 以来的新提交。若发现新提交则自动通过 PAC incoming webhook 触发一次补丁发布。这意味着只要 release 分支上有修复合入周四的例行扫描就会自动产出补丁版本无需人工干预。补丁发布完成后的处理补丁管线成功完成后同样会自动创建 draft GitHub release按上文验收并发布 draft的流程人工 review 并 publish 即可。发布后的收尾步骤Post-Release无论 initial 还是 patch release正式发布后都需要完成以下收尾工作更新 Kubernetes 最低版本要求若本次发布引入了新的最低 Kubernetes 版本需编辑main分支上的 README.md在 Required Kubernetes Version 一节补充新要求。更新 releases.mdPatch release用新版本替换最新条目含 docs 与 examples 链接同时把该补丁追加到补丁版本列表中Minor / major release新增一个独立条目包含 docs 与 examples 链接检查是否有 release 已到EOLEnd of Life如有则将其移入 End of Life Releases 章节。推送并创建 PR将更新后的releases.md与README.md提交推送并创建 Pull Request 合入main。在自有集群实测发布产物这是发布质量最关键的一环# 测试最新版 kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml # 测试回滚版本backport kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/previous/v1.10.1/release.yaml其中release.yaml是发布管线生成的统一安装清单见下文发布产物与镜像发布一节的生成细节latest/路径对应标记为最新版本的产物previous/vX.Y.Z/对应历史版本产物——这两个路径正是由 tekton/release-pipeline.yaml 中publish-to-bucket与publish-to-bucket-latest两个任务的上传前缀决定的。在 Slack 通告在#general、#announcements与#pipelines频道发布发布公告。更新 plumbing 仓库修改tektoncd/plumbing仓库中的tekton/cd/pipeline/overlays/oci-ci-cd/kustomization.yaml第 4 行将最新版本部署到 OCI 上的 dogfooding 集群。major 版本更新网站同步配置对于 major 版本需更新tektoncd/website仓库的sync/config/pipelines.yaml将新版本纳入网站同步范围。Cherry-picking commits补丁发布必备补丁版本需要把main上的修复合入 release 分支推荐使用cherrypicker 插件在被 cherry-pick 的 Pull Request 上评论/cherry-pick branch即可一个分支一条评论。自动化会自动创建一个包含这些提交的 PR针对对应 release 分支。例如修复合入main后在 PR 下评论/cherry-pick release-v1.10.x。若存在合并冲突则手动执行git fetch upstream branchname git checkout upstream/branchname git cherry-pick commit-hash # 解决冲突后 git add changed-files git cherry-pick --continue git push your-fork HEAD:new-branch # 针对 upstream/branchname 打开 PR这套流程与 tekton/README.md 中Create a patch release一节的说明一脉相承建议用 milestone 跟踪待合入的 issue/PR合入后打上needs-cherry-pick标签并用git cherry-pick -x保留原始提交信息全部 cherry-pick 完成后逐一移除标签。Release 命名规范每次发布需要一个符合 **猫品种 著名机器人cat breed famous robot**模式的名称LTS 发布需追加LTS后缀。生成名称使用仓库自带的工具go run tekton/release_names.go该工具的实现位于 tekton/release_names.go从源码可以完整还原其生成逻辑从https://api.thecatapi.com/v1/breeds拉取猫品种列表getCatBreeds从 Wikipedia 的虚构机器人列表页面抓取机器人名字getRobotNames并通过正则b[^]*\s*a[^]*([^])/a\s*/b提取加粗链接的条目名同时截断See also之后的内容以避免误抓非机器人链接通过 GitHub Releases APIgetPastReleases分页per_page100拉取全部历史 release过滤掉已使用过的名称保证唯一性随机选取一个猫品种与机器人首字母相同的组合最多尝试 10 次输出 JSON{ release_name: California Spangled Clank, cat_breed_url: https://en.wikipedia.org/wiki/California_Spangled, robot_url: https://en.wikipedia.org/wiki/Clank }工具从源码结构看还额外输出猫品种与机器人的 Wikipedia 链接便于发布时核对或用于 release 文案。遇到 API 故障等异常时main会输出{error: ...}JSON 便于脚本化调用方处理。发布管线与产物详解源码级发布的核心 Pipeline 是pipeline-release定义在 tekton/release-pipeline.yaml。它接受 18 个参数其中几个关键参数及默认值如下完整清单见文件参数默认值说明packagegithub.com/tektoncd/pipeline要发布的 Go 包路径同时决定镜像命名空间gitRevision必填要发布的 git revisiontag/分支/SHAimageRegistryghcr.io目标镜像仓库imageRegistryPathtekton-releases-nightlystable 模式会被覆盖为tektoncd/pipeline镜像仓库下的项目路径versionTag必填版本 tagstable 为vX.Y.Znightly 为vYYYYMMDD-abc1234releaseBuckettekton-nightlystable 模式覆盖为tekton-releases发布产物存储桶Oracle Cloud StoragereleaseAsLatestfalsestable 模式覆盖是否同时标记并发布为 latestbuildPlatformslinux/amd64,linux/arm64,linux/s390x,linux/ppc64le构建镜像的平台publishPlatforms上述 windows/amd64发布镜像的平台Windows 基础镜像在发布阶段单独构造runTeststrue非true时跳过构建与测试任务previousReleaseTag用于 changelog 的上一个 tag为空时从 git tags 自动探测releaseNamerelease 名称为空时回退为版本号releaseModestablenightly时跳过 Chains 签名校验与 draft release 创建stable时走完整官方发布行为Pipeline 按依赖关系编排以下任务git-clone通过 bundle resolver 引用ghcr.io/tektoncd/catalog/upstream/tasks/git-clone:0.7按gitRevision克隆仓库到workareaworkspaceprecheck从 plumbing 仓库解析prerelease_checks_oci.yaml任务校验包、版本 tag 与 bucketunit-tests / build引用golang-test:0.2与golang-build:0.3./...与./cmd/...仅在runTeststrue时执行when条件publish-images引用本仓库 tekton/publish.yaml 中的publish-releaseTask见下节产出镜像与 release 清单超时 3hpublish-to-bucket / publish-to-bucket-latest通过oracle-cloud-storage-upload:0.2把产物上传到previous/vX.Y.Z/与latest/前缀后者仅在releaseAsLatesttrue时同步deleteExtraFiles: true保证 latest 与当前版本一致report-bucket内联 task构造产物公开 URLhttps://infra.tekton.dev/releaseBucket/repoName/previous/versionTag输出release.yaml与release.notags.yaml两个结果wait-for-chains等待 Tekton Chains 对publish-imagesTaskRun 完成签名通过 Rekor 透明日志检索 in-toto attestationkindintoto的 UUID 供 changelog 引用超时 30 分钟注意该任务不会让管线失败——即使签名超时产物已发布draft 可人工创建源码注释明确说明这一设计意图prepare-draft-release内联 task负责去掉github.com/前缀、从 git tags 自动探测上一个版本 taggit tag --sort-v:refname配合sort -V比较、确定 release 名称create-draft-release引用 plumbing 的github_release_oci.yaml任务结合 changelog 参数previous-release-tag、rekor-uuid与产物路径bucket/$(params.versionTag)创建 draft GitHub release。wait-for-chains、prepare-draft-release、create-draft-release三个任务都带when条件仅当releaseMode stable且github-secretworkspace 已绑定$(workspaces.github-secret.bound) true时执行——这正是上文未绑定 secret 则手动创建 draft的源码依据。发布产物与镜像发布publish.yamltekton/publish.yaml 定义了publish-releaseTask是publish-images任务的实现负责构建并发布全部 7 个 controller 组件镜像controller webhook entrypoint nop workingdirinit resolvers sidecarlogresults events与仓库cmd/目录下的各个 main 包一一对应。关键步骤container-registry-auth用crane登录目标 registry含多 region 登录create-ko-yaml以仓库.ko.yaml为基础生成合并了 Windows 基础镜像nanoserver ltsc2019/ltsc2022通过 plumbing 的combine工具合并 distroless 静态基础镜像的.ko.yamlrun-ko用ko resolve生成两份发布清单并写入$(workspaces.output.path)/$(params.versionTag)release.yaml镜像引用带 tagimage:tagdigest形式release.notags.yaml无 tag 版本供不支持image-reference:tagdigest写法的容器运行时如 cri-o使用随后用sed把清单中的pipeline.tekton.dev/release: devel、app.kubernetes.io/version: devel、version: devel统一替换为$(params.versionTag)保证安装产物带正确的版本标签。发布前还会把vendor/打包进各cmd/*/kodata/目录以满足部分依赖的许可证要求koparse解析release.yaml提取实际构建出的镜像摘要digesttag-images用crane cp为镜像打versionTag与releaseAsLatesttrue时latest标签并把IMAGE_WITH_SHA写入results.IMAGES——该结果正是wait-for-chains任务在 Rekor 中检索 attestation 的数据来源。基础设施速览官方发布依赖的共享基础设施如下组件地址/名称用途PAC controllerhttps://pac.infra.tekton.dev监听仓库事件并触发发布 PipelineRunTekton Dashboardhttps://tekton.infra.tekton.dev查看releases-pipeline命名空间下的发布运行状态Release namespacereleases-pipeline发布 PipelineRun 的运行命名空间Release buckettekton-releasesOracle Cloud Storage存放release.yaml等发布产物Image registryghcr.io/tektoncd/pipeline官方发布镜像的存储位置tekton/目录还提供了配套的发布资源tekton/account.yaml发布用 ServiceAccountrelease-right-meow引用release-secret、git-resolver-secret、release-images-secret三个 secret及配套 Role/RoleBindingpipeline-role覆盖 services/configmaps/secrets/deployments/tekton.dev 资源与 pods 日志读取tekton/kustomization.yamlkustomize 资源清单统一管理publish.yaml与release-pipeline.yaml两个文件tekton/README.md详细的发布环境搭建指南包括安装 Tektonkubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/previous/v${TEKTON_VERSION}/release.yaml、安装 catalog 与 plumbing 中的 Task、连接 OCI 上的 dogfooding 集群等步骤并说明 OCI 凭据 secret 已由 terraform 预置在 dogfooding 集群中发布管理者无需手工创建。常见注意点与最佳实践结合速查表与源码发布过程中有几个容易被忽略但值得特别注意的点版本号只在 initial release 由分支名推导release-v1.10.x → v1.10.0patch 版本的versionTag由 webhook payload 显式传入.tekton/release-patch.yaml中的{{ version }}两者路径不同不要混用。draft release 是人工把关点自动创建 draft 之后必须人工核对提交列表、补充 upgrade/deprecation 说明并取消 pre-release 勾选这是发布质量的核心保障。若github-secret未绑定管线会自动跳过 draft 相关任务此时需按速查表手动创建。发布实测不可省略kubectl apply验证latest/release.yaml与previous/vX.Y.Z/release.yaml两步是发现产物问题如镜像引用写法与运行时不兼容的最后防线——release.notags.yaml的存在正是为了兼容不支持tagdigest写法的运行时。Chains 签名超时不影响发布wait-for-chains任务设计为不失败源码注释明确产物照常发布draft 可人工创建但正常路径下建议等待签名完成以便 changelog 中带上 Rekor 的 in-toto attestation UUID增强发布的可追溯性。补丁发布的提交治理优先用/cherry-pick插件冲突时手动 cherry-pick配合 milestone 与needs-cherry-pick标签见 tekton/README.md可系统化跟踪补丁范围避免遗漏。每周四 10:00 UTC 的 cron 扫描是补丁发布的自动兜底只要 release 分支有新提交就会自动产出补丁版本因此发布管理者应保持 release 分支的整洁只合入确需回传的修复。赞分享云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载相关推荐PyInstaller 发布指南从 develop 分支到 PyPI 的完整发布流程PyInstaller 发布指南从 develop 分支到 PyPI 的完整发布流程 本文是一份围绕 PyInstaller 仓库 release/READM开发工具构建工具Blender 官方 bpy 的 PyPI 发布流程从构建触发到 twine 上传的完整指南Blender 官方 bpy 的 PyPI 发布流程从构建触发到 twine 上传的完整指南 本篇技术指南以 Blender 仓库中 release/pypi图形学3D渲染桌面应用音视频Tekton Pipelines 的自举式发布用 Tekton 构建、测试与发布 Tektontekton/ 目录 CI/CD 全解析Tekton Pipelines 的自举式发布用 Tekton 构建、测试与发布 Tektontekton/ 目录 CI/CD 全解析 本指南围绕当前仓库云原生CI/CDDevOps后端上一篇vuepress-theme-vdoing静态生成预渲染的优势下一篇InternLM2.5-1.8B-Chat安全使用指南避免AI生成有害内容的5个策略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考