背景：尽管通过了初始的LUCI检查，但https://go.dev/cl/565255在各种端口上引入了故障(#65906, #65907)。
这是一个涉及GOOS/GOARCH特定网络行为的CL,因此不足以充分测试它并不令人惊讶。
对于像这样的奇怪CL,应该有一个明确的测试路径。您可以手动向LUCI添加其他配置，但这需要在Gerrit UI中进行大量的点击操作，并且需要手动决定要添加哪些配置。我们不需要一个单一的“测试更难”按钮(虽然那会很好),但至少应该有一份记录的步骤说明，当对更有可能比常规出现故障模式的CL进行预提交测试时，应该采取哪些步骤。
7条答案
按热度按时间vcirk6k61#
关于“测试更难”的按钮，你可以想象一个特殊的构建器叫做“x_net-full”或者其他什么，它实际上只是一个代理构建器。它理解在postsubmit中实际工作的构建器集合，这些构建器还没有在默认的presubmit集合中。它为它们启动构建并等待它们完成。它启动的下游构建也能够独立地出现在Gerrit UI中。
我认为实现这个功能并不会太困难，但仍然需要额外的工作。
kqqjbcuj2#
See also:
v8wbuo2f3#
对于这个特定的用例，我想知道是否只需要过滤掉所有不受支持的构建器(是否有跟踪问题？),并添加一个“全选”按钮就足够了。
kzmpq1sx4#
CC @golang/release。
k97glaaz5#
@bcmills 这个方法也可以，但是因为预提交集不会自动更新，除非你修改提交信息，所以列表会非常长。这并不是一个技术问题，但对于人类来说阅读起来很烦人。这里有一个跟踪问题(尽管它以一种间接的方式请求),编号为 https://issues.chromium.org/issues/40287467 。
目前没有针对这个问题的跟踪。我会提交一个。我最近研究了如何通过合并构建器定义来缩小构建器集，以便列出的所有构建器都始终适用。
另外，我也应该有一个跟踪问题来过滤掉已知问题的构建器。这很容易做到，我们应该这样做。在那之后剩下的只是不适用构建器(例如，针对主分支的 CL 的 go1.22-linux-amd64)。
soat7uwm6#
过滤已知问题构建器
我对此表示怀疑。如果我的CL应该修复已知问题构建器，那么我该如何测试它？
68bkxrlz7#
哦，我明白你的意思了。显然我没有仔细考虑过这个问题。