企业官网建设流程全解析

• 云原生
• CI/CD
• DevOps
• 后端

本篇速查表面向 Tekton Pipelines 的发布管理者（release manager），系统梳理该项目基于 Pipelines-as-Code（PAC）的自动化发布机制：如何通过创建release-vX.Y.x分支触发 initial release（major/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-Code（PAC）驱动。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 Release（major/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。发布管理者需要人工完成以下验收步骤：

1. 手动补充upgrade（升级）与 deprecation（弃用）说明；
2. 核对提交列表是否与预期一致；
3. 取消勾选 "This is a pre-release"（正式发布不应标记为预发布）；
4. 点击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 Release（bugfix 补丁发布）

Patch release 支持手动触发与**自动触发（每周 cron）**两种方式，两者最终都通过 PAC incoming webhook 进入 .tekton/release-patch.yaml 定义的 PipelineRun。

手动触发（workflow_dispatch）

1. 打开 GitHub 仓库的Actions → Patch Release工作流（对应patch-release.yamlworkflow）；
2. 点击Run workflow；
3. 填写参数：
   • release branch：如release-v1.10.x；
   • version：如v1.10.1（遵循 semver 的补丁版本号递增规则）；
   • "Publish as latest release"：按需设置是否将本次补丁标记为最新版本；
4. 再次点击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，正式发布后都需要完成以下收尾工作：

1. 更新 Kubernetes 最低版本要求：若本次发布引入了新的最低 Kubernetes 版本，需编辑main分支上的 README.md，在 "Required Kubernetes Version" 一节补充新要求。

2. 更新 releases.md：

   • Patch release：用新版本替换最新条目（含 docs 与 examples 链接），同时把该补丁追加到补丁版本列表中；
   • Minor / major release：新增一个独立条目，包含 docs 与 examples 链接；
   • 检查是否有 release 已到EOL（End of Life），如有则将其移入 "End of Life Releases" 章节。

3. 推送并创建 PR：将更新后的releases.md与README.md提交推送，并创建 Pull Request 合入main。

4. 在自有集群实测发布产物（这是发布质量最关键的一环）：

   # 测试最新版 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两个任务的上传前缀决定的。

5. 在 Slack 通告：在#general、#announcements与#pipelines频道发布发布公告。

6. 更新 plumbing 仓库：修改tektoncd/plumbing仓库中的tekton/cd/pipeline/overlays/oci-ci-cd/kustomization.yaml（第 4 行），将最新版本部署到 OCI 上的 dogfooding 集群。

7. 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 API（getPastReleases，分页per_page=100拉取全部历史 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 个参数，其中几个关键参数及默认值如下（完整清单见文件）：

Pipeline 按依赖关系编排以下任务：

1. git-clone：通过 bundle resolver 引用ghcr.io/tektoncd/catalog/upstream/tasks/git-clone:0.7，按gitRevision克隆仓库到workareaworkspace；
2. precheck：从 plumbing 仓库解析prerelease_checks_oci.yaml任务，校验包、版本 tag 与 bucket；
3. unit-tests / build：引用golang-test:0.2与golang-build:0.3（./...与./cmd/...），仅在runTests=true时执行（when条件）；
4. publish-images：引用本仓库 tekton/publish.yaml 中的publish-releaseTask（见下节），产出镜像与 release 清单，超时 3h；
5. publish-to-bucket / publish-to-bucket-latest：通过oracle-cloud-storage-upload:0.2把产物上传到previous/vX.Y.Z/与latest/前缀（后者仅在releaseAsLatest=true时同步，deleteExtraFiles: "true"保证 latest 与当前版本一致）；
6. report-bucket：内联 task，构造产物公开 URLhttps://infra.tekton.dev/<releaseBucket>/<repoName>/previous/<versionTag>，输出release.yaml与release.notags.yaml两个结果；
7. wait-for-chains：等待 Tekton Chains 对publish-imagesTaskRun 完成签名，通过 Rekor 透明日志检索 in-toto attestation（kindintoto）的 UUID 供 changelog 引用，超时 30 分钟；注意该任务不会让管线失败——即使签名超时，产物已发布，draft 可人工创建（源码注释明确说明这一设计意图）；
8. prepare-draft-release：内联 task，负责去掉github.com/前缀、从 git tags 自动探测上一个版本 tag（git tag --sort=-v:refname配合sort -V比较）、确定 release 名称；
9. 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.yaml）

tekton/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.yaml；
• run-ko：用ko resolve生成两份发布清单并写入$(workspaces.output.path)/$(params.versionTag)：
  • release.yaml：镜像引用带 tag（image:tag@digest形式）；
  • release.notags.yaml：无 tag 版本，供不支持image-reference:tag@digest写法的容器运行时（如 cri-o）使用；
  • 随后用sed把清单中的pipeline.tekton.dev/release: "devel"、app.kubernetes.io/version: "devel"、version: "devel"统一替换为$(params.versionTag)，保证安装产物带正确的版本标签。发布前还会把vendor/打包进各cmd/*/kodata/目录以满足部分依赖的许可证要求；
• koparse：解析release.yaml提取实际构建出的镜像摘要（digest）；
• tag-images：用crane cp为镜像打versionTag与（releaseAsLatest=true时）latest标签，并把IMAGE_WITH_SHA写入results.IMAGES——该结果正是wait-for-chains任务在 Rekor 中检索 attestation 的数据来源。

基础设施速览

官方发布依赖的共享基础设施如下：

tekton/目录还提供了配套的发布资源：

• tekton/account.yaml：发布用 ServiceAccountrelease-right-meow（引用release-secret、git-resolver-secret、release-images-secret三个 secret）及配套 Role/RoleBinding（pipeline-role，覆盖 services/configmaps/secrets/deployments/tekton.dev 资源与 pods 日志读取）；
• tekton/kustomization.yaml：kustomize 资源清单，统一管理publish.yaml与release-pipeline.yaml两个文件；
• tekton/README.md：详细的发布环境搭建指南，包括安装 Tekton（kubectl apply --filename https://infra.tekton.dev/tekton-releases/pipeline/previous/v${TEKTON_VERSION}/release.yaml）、安装 catalog 与 plumbing 中的 Task、连接 OCI 上的 dogfooding 集群等步骤，并说明 OCI 凭据 secret 已由 terraform 预置在 dogfooding 集群中，发布管理者无需手工创建。

常见注意点与最佳实践

结合速查表与源码，发布过程中有几个容易被忽略但值得特别注意的点：

1. 版本号只在 initial release 由分支名推导：release-v1.10.x → v1.10.0；patch 版本的versionTag由 webhook payload 显式传入（.tekton/release-patch.yaml中的{{ version }}），两者路径不同，不要混用。
2. draft release 是"人工把关点"：自动创建 draft 之后必须人工核对提交列表、补充 upgrade/deprecation 说明并取消 pre-release 勾选，这是发布质量的核心保障。若github-secret未绑定，管线会自动跳过 draft 相关任务，此时需按速查表手动创建。
3. 发布实测不可省略：kubectl apply验证latest/release.yaml与previous/vX.Y.Z/release.yaml两步，是发现产物问题（如镜像引用写法与运行时不兼容）的最后防线——release.notags.yaml的存在正是为了兼容不支持tag@digest写法的运行时。
4. Chains 签名超时不影响发布：wait-for-chains任务设计为不失败（源码注释明确），产物照常发布，draft 可人工创建；但正常路径下建议等待签名完成，以便 changelog 中带上 Rekor 的 in-toto attestation UUID，增强发布的可追溯性。
5. 补丁发布的提交治理：优先用/cherry-pick插件，冲突时手动 cherry-pick；配合 milestone 与needs-cherry-pick标签（见 tekton/README.md）可系统化跟踪补丁范围，避免遗漏。
6. 每周四 10:00 UTC 的 cron 扫描是补丁发布的自动兜底：只要 release 分支有新提交，就会自动产出补丁版本，因此发布管理者应保持 release 分支的整洁，只合入确需回传的修复。

• 云原生
• CI/CD
• DevOps
• 后端