ci(docker): 加并发组 + k8s 清单声明 ghcr 拉取凭证要求（并清掉一条 RP 不消费的手写 [Unreleased]） - #143
Merged
Merged
Conversation
#140 把镜像名修对了，但照着清单上线仍然会失败：ghcr 上那个 `tts_multimodel` 包**不是匿名可拉的** （今天实测：匿名 token 拿不到 grant、manifest GET 四条 tag 全 404；已登录但缺 `read:packages` 的 token 回 403），而 `deploy/kubernetes/` 下原先既没有 `imagePullSecrets`、README 也没有一句 凭证说明。最难查的是**缺这一步时 `kubectl apply` 不报错** —— 它会受理，然后 Pod 一直 `ImagePullBackOff`。 - `deployment.yaml`：Pod spec 里加 `imagePullSecrets: [{name: ghcr-pull}]`，注释写明为什么 不能拿 `GITHUB_TOKEN` 当密码（只对当次 run 有效，且 API 拒绝用它建 registry secret）。 - `deploy/kubernetes/README.md` 前置条件：给出现成的 `kubectl create namespace` + `create secret docker-registry` 两条命令，并点明"别把 apply 成功当成上线成功"。 没有真集群可验（本机没有 k8s，也没有注册 runner），所以这一条的强度只到"清单与文档自洽、 YAML 可解析、`spec.template.spec.imagePullSecrets` 确实解析成 `[{'name': 'ghcr-pull'}]`"； `kubectl apply` 到真集群拉通镜像那一步仍未取证，记在这里。 YAML 用 `yaml.safe_load_all` 复解析过（deployment 2 个文档、workflow 1 个）。 发版链路 3 个文件 16 passed、`check_release_readiness.py` 判"发版条件满足"（11 处 = 2.2.5）。 Signed-off-by: ReSerendipity <zengyangc@outlook.com>
**并发组**：`docker-publish.yml` 之前没有 `concurrency`，2026-09-22 实测到三条构建同日并行 （13:29 与 14:03 两次 main push，加 14:12 我为 v2.2.5 手工 dispatch 的那条），单次 20+ 分钟， 还同时读写同一份 Actions 层缓存 —— 而那份缓存的配额只有 10 GiB，历史上正是被这个工作流的 `mode=max` 吃满过（#133）。 我先想的是按 ref 分组（`docker-publish-${{ github.ref }}`），**自己否掉了**：今天真正重叠的 两条恰好来自不同 ref（`refs/heads/main` 与 `refs/tags/v2.2.5`），分组等于没管住，所以用常量组。 `cancel-in-progress: false`：中途取消会留下半份层缓存、也可能让 `:latest` 停在中间态， release 那条更不能事后被取消。 **`[Unreleased]` 这条是修我自己造成的假账**：#140 里我手写过一条 `## [Unreleased] → ### Bug Fixes` 的条目，以为发版时 RP 会把它折进新版本段。今天开 #141 才看清 它**不读这个段落** —— 它照提交信息另生成两条（真实提交 + merge commit 各一条），把我那段原文 原地留在 `[2.2.5]` 与 `[2.2.4]` 之间。结果就是"已经发出去的内容"永久挂在 Unreleased 底下。 现在删掉那条，并把机制写进 `docs/release-governance.md`：走自动路径时**别手写 `[Unreleased]`**， 要留的说明进提交信息与文档；§2 第 1 步"`[Unreleased]` 收敛进 `[<新版本>]`"那句标注成只对 手工路径成立。 同一条里也记下 RP 的计数形状：#137 与 #141 都把 PR 的真实提交**与 merge commit 各算一条**， 所以 2.2.6 的 CHANGELOG 里同一件事有两行。要治就是仓库侧改用 squash merge，属另一条决定， 这次不动。 Signed-off-by: ReSerendipity <zengyangc@outlook.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
两条独立的小收口 + 一处修我自己造成的假账。2 个提交。
提交 1
fix(deploy):—— 清单声明镜像拉取凭证#140 把镜像名修对了，但照清单上线仍然会失败：ghcr 那个
tts_multimodel包不是匿名可拉的（实测：匿名 token 无 grant、4 条 tag 的 manifest GET 全 404；已登录但缺read:packages的 token 回 403），而deploy/kubernetes/里原先既没有imagePullSecrets、README 也没有一句凭证说明。难查的地方：缺这一步时
kubectl apply不报错 —— 它受理，然后 Pod 一直ImagePullBackOff。deployment.yaml：Pod spec 加imagePullSecrets: [{name: ghcr-pull}]，注释写明为什么密码不能是GITHUB_TOKEN（只对当次 run 有效，API 也拒绝拿它建 registry secret）。deploy/kubernetes/README.md：给出kubectl create namespace+create secret docker-registry两条现成命令。取证强度到此为止：本机没有 k8s（
which kubectl→ not found，也没有注册 runner），所以"真集群 apply 后能拉起镜像"这一格没验过，只验到 YAML 可解析、spec.template.spec.imagePullSecrets == [{'name': 'ghcr-pull'}]。提交 2
ci(docker):—— 并发组之前没有
concurrency，2026-09-22 实测三条构建同日并行（13:29、14:03 两次 main push + 14:12 我为 v2.2.5 dispatch 的那条），单次 20+ 分钟，还同时读写同一份层缓存 —— 那份缓存配额只有 10 GiB，历史上正是被这个工作流的mode=max吃满过（#133）。我本来想按 ref 分组（
docker-publish-${{ github.ref }}），自己否了：今天真正重叠的两条恰好来自不同 ref（refs/heads/main与refs/tags/v2.2.5），分组等于没管住 → 用常量组。cancel-in-progress: false：取消会留半份层缓存、可能让:latest停在中间态，release 那条更不能事后取消。顺手清掉一条我写的假账（同一提交里说明）
#140 里我手写过一条
## [Unreleased] → ### Bug Fixes，以为发版时 RP 会把它折进新版本段。开 #141 才看清它不读这个段落：它按提交信息另生成两条，把我那段原文原地留在[2.2.5]与[2.2.4]之间 —— 于是"已经发出去的内容"永久挂在 Unreleased 底下。现在删掉，并把机制写进 §1 末、把 §2 第 1 步那句"[Unreleased]收敛进[<新版本>]"标注成只对手工路径成立。同处记下 RP 的计数形状：#137/#141 都把真实提交与 merge commit 各算一条，所以 2.2.6 的 CHANGELOG 里同一件事有两行。要治是仓库侧改 squash merge，这次不动。
验证
yaml.safe_load_all复解析：workflow 1 个文档、deployment 2 个文档；concurrency == {group: docker-publish, cancel-in-progress: False}、imagePullSecrets == [{'name': 'ghcr-pull'}]。tests/test_image_name_consistency.py+test_version_consistency.py+test_release_readiness_gate.py→ 16 passed；scripts/check_release_readiness.py --root .→ 发版条件满足（11 处版本位 = 2.2.5）。合并顺序有意为之
这条先合。提交 2 是
ci:（实测不算 user facing，不会 mint 版本），提交 1 是fix(deploy):→ 会被 #141 吸收进去，2.2.6 就带上"凭证要求"这一条真内容。手工同步位要等这条合完、RP 刷完分支之后再补，否则会被重写冲掉。