PR #7:CNB services image 陷阱根治——coverage 收敛 unit-only + -D 覆盖阈值#7
PR #6 远端 biz-backend-coverage 跑了 91.7s 后 fail。截图深度解读发现之前未知的 CNB 平台行为:
biz-backend-coverage
services: [docker] 会强制忽略 image: 字段,改用 cnbcool/default-build-env 默认镜像
services: [docker]
image:
cnbcool/default-build-env
这是 CNB 平台行为,grammar.html 未说明。PR #6 的诊断截图关键行:
grammar.html
CNB_PIPELINE_DOCKER_IMAGE=cnbcool/default-build-env ← 即使 .cnb.yml 写 image: maven:* 安装 docker CLI (静态二进制)... docker 已安装: /usr/local/bin/docker ← install_docker_cli 成功 [WARN] Docker 不可用——降级到 unit-only 覆盖率度量 ← CLI 装了但 docker info 失败 ArticleServiceImpl -- 创建 Article 成功 ← mvn verify 实际跑了 [ERROR] jacoco:0.8.14:check Coverage checks not met ← pom 阈值 0.78 不通过 [FAIL] mvn verify 失败(unit-only 降级模式)
3 重错位:
services:[docker]
default-build-env
install_docker_cli
docker info
LINE_MIN=36
mvn verify
<jacoco.line.min>0.78
单 commit 16d176c:3 文件 / +108/-249(重大简化)
16d176c
.cnb.yml
- name: biz-backend-coverage image: maven:3.9-eclipse-temurin-17 - services: - - docker script: - sh scripts/ci/backend/check-backend-coverage.sh
让 maven image 真正生效(显式、干净)。biz-backend-functional stage 保留 services:[docker] 继续尝试 docker。
biz-backend-functional
check-backend-coverage.sh
DOCKER_HOST
-D
mvn -B -Dtest='com.example.demo.unit.**' \ -Djacoco.line.min=0.36 \ -Djacoco.branch.min=0.46 \ verify
CHECKPOINT §四 轮次 3.3
本地 15/15 CI stages 全绿 + 0 lint + yml 对称 79/79 行
coverage.sh 本地实测:
==> P1 后端覆盖率棘轮 (JaCoCo, unit-only; 阈值 0.36/0.46) 行覆盖(unit-only): 79% 保底: 36% 分支覆盖(unit-only): 71% 保底: 46% [OK] 后端 unit-only 覆盖率棘轮达标
(本地残留之前 unit+functional 合并 CSV 所以显示 79%;远端从零跑会是 ~36% 真值,仍通过)
pom.xml
两个口径各自棘轮,互不干扰。meta-principles §原则 3 "棘轮只上不下"的**"同一口径"**约束在此首次规则化。
meta-principles §原则 3
每一步都是对平台行为的新认知。没有捷径跳过"盲猜 → 实证"的过程——这是 B14 候选反模式(未经实证推断平台行为)的正面闭环实证。
B14 候选反模式
cnb-m1g-1jnn5kaqu
meta-principles §原则 2
LESSONS B14 候选
动机(Why)
PR #6 远端
biz-backend-coverage跑了 91.7s 后 fail。截图深度解读发现之前未知的 CNB 平台行为:这是 CNB 平台行为,
grammar.html未说明。PR #6 的诊断截图关键行:3 重错位:
services:[docker]导致 CNB 强制default-build-env(非 maven image)install_docker_cli装上 CLI 但docker info仍失败——sidecar daemon 可能未启动或端点未知LINE_MIN=36未传递到mvn verify;后者读 pom 的<jacoco.line.min>0.78必然失败变更清单(What)
单 commit
16d176c:3 文件 / +108/-249(重大简化)改动 1:
.cnb.ymlcoverage stage 去services:[docker](push + MR 2 处)- name: biz-backend-coverage image: maven:3.9-eclipse-temurin-17 - services: - - docker script: - sh scripts/ci/backend/check-backend-coverage.sh让 maven image 真正生效(显式、干净)。
biz-backend-functionalstage 保留services:[docker]继续尝试 docker。改动 2:
check-backend-coverage.sh大幅简化(170 → 70 行)install_docker_cli/DOCKER_HOST探测 / 双路径逻辑-D覆盖 pom 阈值mvn -B -Dtest='com.example.demo.unit.**' \ -Djacoco.line.min=0.36 \ -Djacoco.branch.min=0.46 \ verify改动 3:
CHECKPOINT §四 轮次 3.3档案services:[docker]的真实行为实证记录(反馈到源仓库的 T-Q2-e 候选)验证证据(How verified)
本地 15/15 CI stages 全绿 + 0 lint + yml 对称 79/79 行
coverage.sh 本地实测:
(本地残留之前 unit+functional 合并 CSV 所以显示 79%;远端从零跑会是 ~36% 真值,仍通过)
影响面(Impact)
棘轮"口径区分版"的具体落地
biz-backend-coverage-D命令行覆盖 pombiz-backend-functionalpom.xml(本地mvn verify)两个口径各自棘轮,互不干扰。
meta-principles §原则 3"棘轮只上不下"的**"同一口径"**约束在此首次规则化。预期远端行为
biz-backend-coverage远端耗时连续 4 PR(#4~#7)的工程演化
每一步都是对平台行为的新认知。没有捷径跳过"盲猜 → 实证"的过程——这是
B14 候选反模式(未经实证推断平台行为)的正面闭环实证。关闭待办(预期,待 PR #7 验证)
仍悬而未决
本 PR 不动的事
biz-backend-functionalstage 保持 PR #6 状态(install_docker_cli 逻辑),本 PR 不纠结它——等 coverage 跑通后独立迭代Refs
cnb-m1g-1jnn5kaqucoverage stage 91.7s fail + 截图诊断CHECKPOINT §四 轮次 3.3完整档案meta-principles §原则 2(收敛到可执行子集)meta-principles §原则 3(棘轮口径区分版——Maven -D 的首次规则化应用)LESSONS B14 候选的正面闭环(4 PR 递进)