Looking at our build dashboard for first-class ports, windows-arm-zx2c4 stands out as failing for a long time.
Some of the failures might be due to resource constraints (gopls tests can be very IO and memory heavy), but some are failures related to the filesystem that should be investigated, for example:
https://build.golang.org/log/477a5faf3f4383900706c4b25940a706322b6362
--- FAIL: TestLSP (23.64s)
--- FAIL: TestLSP/Modules (8.57s)
lsp_test.go:57: invalid workspace configuration: case mismatch in path "C:\\Users\\GOPHER~1.DES\\AppData\\Local\\Temp\\TestLSP_Modules233674203\\lsp": component "GOPHER~1.DES" should be "Gopher.DESKTOP-6IM5GCA"
--- FAIL: TestCaseInsensitiveFilesystem (0.02s)
view_test.go:50: checkPathCase("C:\\Users\\GOPHER~1.DES\\AppData\\Local\\Temp\\TestCaseInsensitiveFilesystem086638055\\a\\B\\c\\DEFgh\\f.go") = case mismatch in path "C:\\Users\\GOPHER~1.DES\\AppData\\Local\\Temp\\TestCaseInsensitiveFilesystem086638055\\a\\B\\c\\DEFgh\\f.go": component "GOPHER~1.DES" should be "Gopher.DESKTOP-6IM5GCA", wanted error: false
Opening this issue to track getting this builder out of failure, either by deciding to skip these tests or by fixing them.
CC @stamblerre @heschik @pjweinbgo
7条答案
按热度按时间nkkqxpd91#
我怀疑这是由于TMP/TEMP被设置为一个较长的值所导致的。我会尝试将其设置为一个较短的值。
xxhby3vn2#
好的,现在它设置为
C:\temp
,而不是带有8.3缩写的那个东西。让我们看看这是否解决了一些问题。wfypjpf43#
在某些方面,该构建器确实很慢,因此它有一个习惯,即暴露出需要大量资源或对计时做出无效假设的测试。(参见 #42925 , #43120 , #43668 。)
okxuctiv4#
是的,我怀疑我们需要跳过资源密集型测试,但这些路径错误尤其值得考虑。
另外,作为一个澄清点,这不是一个第一类端口(参见 #27689 )。
gtlvzcf85#
/cc @zx2c4
zwghvu4y6#
case mismatch
故障仍然存在。测试似乎假设某个组件是通过其长名称来引用的,但这个构建器却是通过其短名称来引用的。(许多Windows文件系统允许每个路径组件既可以通过8.3名称来引用,也可以通过更长的名称来引用。测试需要对Windows上的这些变体进行冗余处理,就像它们需要对macOS上的
PWD
符号链接进行冗余处理一样。)dojqjjoe7#
CC @zx2c4