Repository navigation
chore(build): document RELEASE_TAG and warn on an untraceable version - #654
Merged
Merged
Conversation
RELEASE_TAG is read by exactly one line of hack/version.sh, is set by nothing in this repository, and is undocumented anywhere. This records what it is actually for, based on testing the three paths through the script. Evaluation ---------- The version is resolved in this order: RELEASE_TAG, then `git tag -l --contains HEAD`, then "$VERSION_K8S+k8e-<commit8>". - In-repo CI needs RELEASE_TAG for nothing. release.yml builds with the default shallow `actions/checkout`, which still fetches tags pointing at the checked-out commit; a `--depth 1` clone of this repo resolves the current merge to `v1.37.0-20261018-rc1`. Verified against a real shallow clone. - Building a copied source tree needs it, and this is the only case that exercises it. With no `.git` the tag lookup is skipped by the `if [ -d .git ]` guard, so the version degrades to `v1.37.0+k8e-`: empty commit, trailing dash, and `v1.37.0-k8e-` once '+' is rewritten for an image tag — invalid in both places. No in-repo Dockerfile builds the binaries (they all COPY from bin/), which is why this has never surfaced. So the variable is meaningful but currently dead: it exists for release tarballs and vendored/air-gapped builds that no workflow in this repo performs. Changes ------- - Document what it is for and when to set it, above the assignment. - Warn on stderr when neither a tag nor a commit is available, so a `v1.37.0+k8e-` build announces itself instead of shipping quietly. Warnings only: the script's stdout is what build.zig's getVersionEnv parses for VERSION, and it stays clean (checked). - Quote the assignment. Hygiene only — bash does not word-split an assignment's right-hand side, so "$RELEASE_TAG" and $RELEASE_TAG already assign identically. An earlier claim that this fixed a splitting bug was wrong; the comment says so rather than repeating it. Verified: the repo path still resolves to v1.37.0-20261018-rc1, the no-.git path warns with VERSION=v1.37.0+k8e-, and RELEASE_TAG=v1.37.0-rc9 resolves cleanly with no warning. `zig build sandboxd` and the Go suites pass; `zig build k8e` fails with `ld: library 'crt0.o' not found` identically on main (missing Xcode CLT on this host, unrelated).
|
Contributor
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.
结论：
RELEASE_TAG有意义，但目前在仓库内是死配置它只被
hack/version.sh:7一行读取，仓库里没有任何地方设置它，也没有任何文档提到它。我把脚本的三条路径都实测了一遍：版本解析顺序：
RELEASE_TAG→git tag -l --contains HEAD→$VERSION_K8S+k8e-<commit8>RELEASE_TAGv1.37.0-20261018-rc1.git）+ 未设 RELEASE_TAGVERSION=v1.37.0+k8e-，commit 为空VERSION=v1.37.0-rc9仓库内 CI 不需要它：
release.yml用默认的 shallowactions/checkout，而 GitHub 仍会拉取指向被检出 commit 的 tag。我用--depth 1真实克隆验证过，当前 merge commit 解析为v1.37.0-20261018-rc1。只有一种场景真正需要它：构建一个拷贝出来的源码树（发布 tarball、vendored/air-gap 构建、没有
.git的 Docker context）。此时if [ -d .git ]会整段跳过 tag 查找，版本退化成v1.37.0+k8e-——commit 为空、末位一个连字符，+换成-之后变成v1.37.0-k8e-，两处都非法。仓库内没有任何 Dockerfile 自己编译二进制（都是COPY bin/），所以这个问题一直没暴露。也就是说：这个变量是有价值的，但对当前仓库的所有工作流都是死代码——它服务于本仓库没有执行的那些打包方式。
改动
在赋值处补文档——说明用途、何时该设置、不设置会怎样。
拿不到 tag 也拿不到 commit 时，向 stderr 报警（原先是静默产出
v1.37.0+k8e-）。只报警不改退出码，因为build.zig的getVersionEnv解析的是 stdout，我验证过 stdout 保持干净、VERSION/VERSION_TAG/COMMIT不受影响。给赋值加引号——纯粹是卫生习惯，不是修 bug：bash 不会对赋值语句右侧做 word splitting，
"$RELEASE_TAG"和$RELEASE_TAG赋值结果完全一致（已实测）。注释里写明了这一点，免得把错误结论传下去。验证
另外：
source hack/version.sh的 stdout 不含 warning（不会污染build.zig解析）；zig build sandboxd与 Go 测试通过；zig build k8e在本机报ld: library 'crt0.o' not found——main 上一模一样（本机缺 Xcode CLT，与本次改动无关）。顺带发现
PR #653 已合并，release tag
v1.37.0-20261018-rc1就打在 merge commit 上——这也是上面第 1 条结论的直接证据。