update-project-versions and verify-no-snapshot-versions can drift with nothing testing the pair
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 56/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- javascript
调研方向
先从 .github/actions/update-project-versions/src/index.js 和 .github/actions/verify-no-snapshot-versions/src/index.js 开始，然后阅读这两个 actions 现有的测试套件。为每种文件类型添加一个 fixture，覆盖 verifier 的版本位置，一起运行 updater 和 verifier，并将以下内容定义为完成标准：没有意外的违规项，并且对未管理的版本形式值进行可见报告。
由索引模型根据 Issue 内容生成。
描述
verify-no-snapshot-versions rejects versions in locations that update-project-versions never writes, so a release can fail its own gate on something the automation was supposed to have fixed. Nothing tests the two actions together, so the two sides can drift silently.
How it surfaced
spring-cloud-function-commercial 5.0.4 passed readiness on 2026-08-04. spring-cloud-function-commercial release/5.1.0-M1 failed on 2026-09-07 with 12 violations, all in spring-cloud-function-samples/**/build.gradle.
Running each historical verifier against the same unchanged file:
| Verifier | Date | Violations |
|---|---|---|
b950928 |
2026-06-25 | 1 — version = only |
a760372 |
2026-08-08 | 3 — plus springBootVersion, springCloudFunctionVersion |
a760372 broadened the verifier to nested locations, which for build.gradle swept in ext { xxxVersion = ... } blocks. updateBuildGradleContent only ever rewrote the single version = '...' line, so the two stopped agreeing. Both actions' test suites stayed green for a month, because neither exercises the other.
The build.gradle half is now fixed — the updater resolves {prefix}Version properties the way gradle.properties already did, and rewrites inline org.springframework.* dependency coordinates for artifacts the train releases.
Still open
| Location | Verifier | Updater |
|---|---|---|
settings.gradle, settings.gradle.kts |
checks | never opens the file |
pom inline <dependency> / <plugin> / <extension> <version> |
checks | reads, never writes — it writes only the project version, the parent version and properties |
Neither has bitten yet: Spring Cloud poms express dependency versions through properties, and versions in settings.gradle are unusual. Both are the same shape as the bug above, waiting on the right repository.
Why identical coverage is the wrong goal
The verifier must catch things the updater must never touch. A -SNAPSHOT on a third-party dependency has to fail the release, and rewriting it to a Spring Cloud version would be wrong — that is exactly what a760372 was added for. The invariant worth enforcing is narrower:
Every location the verifier rejects is either one the updater fixed, or one nothing could fix — and the second kind is visible before the release, not at the gate.
Suggested approach
- A conformance test. One fixture per file type, with a version in every location the verifier knows about. Run updater, then verifier, assert zero violations. This is the test that did not exist on 2026-08-08: it would have failed the moment the verifier was broadened. Cheap, and needs no refactoring. The fixture doubles as a readable specification of every place a version is managed.
- Have the updater report what it skipped. When it meets a version-shaped value it cannot map to a project, log it as unmanaged. Turns a surprise gate failure into a visible line at stamp time, and covers the genuinely unfixable third-party case too.
- A shared location model, only if divergence continues. One module enumerating version locations per file type, with the verifier flagging them and the updater writing those that resolve to a project. Makes divergence structurally impossible rather than merely tested against, at the cost of refactoring two actions that carry ~200 tests between them.
Recommend 1 and 2; keep 3 in reserve.
References
- Failing run: https://github.com/spring-cloud/spring-cloud-github-actions/actions/runs/34133819801
a760372— the verifier broadening.github/actions/verify-no-snapshot-versions/src/index.js.github/actions/update-project-versions/src/index.js
- 主要语言
- 没有语言数据
- 星标
- 0
- 派生
- 0
- 平均合并
- 14 小时 22 分钟
- 30 天内合并 PR
- 4
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
spring-cloud/spring-cloud-github-actions 的其他 Issue
-
bug
难度 3/5 1-2 天 新手友好度 52/100
-
难度 4/5 3-5 天 新手友好度 48/100
-
难度 3/5 1-2 天 新手友好度 55/100
-
Replace release-ci-settings.xml with maven-settings-action repository config可能重新可做 @ryanjbaxter 于 62 天前认领，目前没有进行中的 PR。 未关闭
spring-cloud/spring-cloud-github-actions#5 · 1 条评论 · 已指派 1 人 ·
查看 spring-cloud/spring-cloud-github-actions 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 86/100
lawndoc/stack-back#122 ·
-
software-development-practices software-development-practices:nist-ssdf
难度 2/5 1-3 小时 新手友好度 82/100
githubnext/gh-aw-cao#15860 ·
维护者通常 1 天内回复
-
framework/gatsby help wanted kind/bug
难度 2/5 1-3 小时 新手友好度 87/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
enhancement
难度 1/5 1 小时以内 新手友好度 92/100