你正在使用的Go版本是什么(go version
)?
$ go1.20.2 version
go version go1.20.2 windows/amd64
这个问题在最新版本的发布中是否重现?
我没有尝试,但从当前的代码来看,是的。
你正在使用什么操作系统和处理器架构(go env
)?go env
输出
$ go1.20.2 env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Matt\AppData\Local\go-build
set GOENV=C:\Users\Matt\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Matt\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Matt\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Users\Matt\sdk\go1.20.2
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\Matt\sdk\go1.20.2\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20.2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\Matt\AppData\Local\Temp\go-build3808080945=/tmp/go-build -gno-record-gcc-switches
你做了什么?
我在可执行文件上运行了go1.20.2.exe version -m
。
你期望看到什么?
build vcs=hg
build vcs.revision=76cef81bcff371c88d277f17c712ecf22b8c83e7
build vcs.time=2023-10-12T23:09:25Z
build vcs.modified=true
你看到的是什么?
build vcs=hg
build vcs.revision=82be5bac456b8fbde0268380e336fe2fbd1294e7
build vcs.time=2023-09-28T04:18:18Z
build vcs.modified=true
看起来当从identify -i
(生成关于当前检出的信息的命令)切换到log -l1
(打印关于最顶层提交的信息,可能是一个完全不同的分支)时,76cef81引入了一个回归。从提交评论中可以看出,这个特定的更改是为了获取完整的提交哈希值。这里的修复方法是在log
命令中添加一个-r.
参数来查看当前提交,这将解决vcs.time
和vcs.revision
的问题。
通常,最顶层的提交是开发者正在处理的内容,但如果更新到旧的提交或从服务器拉取更改,它就不会是那样。虽然这些可能是边缘情况,但创建标签会创建一个新的提交,而CI通常会更新标记的提交。这意味着对于任何标记的构建,这些信息都是错误的(这就是我注意到的问题)。
这里还有两个其他正确性问题:
status
命令应该有一个-S
参数,这样在检查已修改文件时可以递归到任何子仓库。[2]- 当执行任何命令时,应将环境设置为
HGPLAIN=1
,以防止意外的命令输出更改。[3]例如,我在我的配置中有ui.tweakdefaults=True
,所以在hg status
列出任何文件更改后,它可以像这样打印有关仓库当前状态的信息:
# The repository is in an unfinished *bisect* state.
# To mark the changeset good: hg bisect --good
# To mark the changeset bad: hg bisect --bad
# To abort: hg bisect --reset
考虑到当前检查任何状态输出的代码,这将错误地将构建标记为已修改。
[1] 76cef81#diff-50574a97a14d32e7cc56ad1ba6de8c554e491c48a3718e599cfc8cc0ab2858e4R166
[2] https://github.com/golang/go/blame/cc13161a0d62fc1deab019996c17a7da1ff6a7f1/src/cmd/go/internal/vcs/vcs.go#L211
[3] https://repo.mercurial-scm.org/hg/file/6.5.2/mercurial/helptext/scripting.txt#l45
6条答案
按热度按时间d8tt03nd1#
@mharbison72,鉴于你似乎理解了这里的问题,你想发送一个修复吗?(我不确定我对Mercurial命令行的理解是否足够扎实——尤其是编写一个能够正确重现这些错误的回归测试。)
y53ybaqx2#
@mharbison72,鉴于你似乎理解了这里的问题,你想发送一个修复吗?
(我不确定我对Mercurial命令行的理解是否足够扎实——尤其是要编写一个能够正确重现这些错误的回归测试。)
我也很高兴帮忙,但我以前没有在这里贡献过。我正在阅读贡献文档并需要先进行设置。
我不确定你在发布周期中的位置——是否有一个特定的分支我应该针对以将这些修复回溯移植?此外,我应该在哪里添加测试?我看到
src/cmd/go/internal/vcs/vcs_test.go
和src/cmd/go/testdata/vcstest/hg
,我猜想这就是你的意思,但我不确定如何运行它们。通常的工作流程是只推送到PR,然后让测试在GitHub上运行吗?xggvc2p63#
我不确定您在发布周期的哪个阶段- 是否有一个特定的分支,我应该针对这些修复进行回溯?
所有修复应首先登陆在
master
分支上;然后我们可以决定关于回溯的事情。此外,我应该添加哪些测试?
src/cmd/go/testdata/script
— 特别是src/cmd/go/testdata/script/version_buildvcs_hg.txt
。它们作为
cmd/go.TestScript
的子测试运行,因此您可以像这样单独调用它们:ig9co6j14#
感谢@bcmills的指正。我可能遗漏了一些显而易见的东西,但当我在详细模式下运行测试命令时,测试似乎会忽略我在
version_buildvcs_hg.txt
上所做的更改,即使禁用了缓存:此外,如果我理解脚本是如何工作的,它们目前根本不在测试修订或时间值,除了它们存在之外:
我知道为什么要这样做-当前时间和用户名是提交哈希的一部分,因此它们不会在每次运行时固定。它们可以在测试环境中设置为特定值,就像在Mercurial测试设置中那样(如果你想那么做的话),但是我不想给你们留下一堆复杂性。如果没有它,实际上没有办法为这个添加回归测试。
1mrurvl15#
我发现了我的问题——我运行的是全局的
go
,而不是本地的来运行测试。如果你想要更详细的修订匹配在测试中,请告诉我,或者你指的是其他什么。
oxalkeyp6#
https://go.dev/cl/535377提到了这个问题:
cmd/go: fix the accuracy of Mercurial vcs.* stamped data