动机
- 需要积极降低CI成本，因为当前的燃烧速率对于vLLM来说是不可持续的。
- 目前，我们对每个PR的每个提交都运行完整的CI测试，这相当多且不必要的。
建议的变更
这是ray CI正在使用的相同工作流程，我认为在维护相同的CI信号和成本减少方面它表现得很好。我认为vLLM也会从同样的系统中受益。
我们可以将单一的CI管道分解为3个不同的管道，每个管道服务于不同的目的。
1. Fast-check 管道
- 目的:快速捕获PR提交之间的小错误，这些错误不需要不必要的测试。
- 运行一小部分快速、基本且必要的测试(例如基本正确性、回归、引擎、核心等)。
- 在PR内的每个提交上触发。
2.Pre-merge管道 - 目的:尽可能多地捕获错误，然后将PR合并到主分支。
- 现在运行所有测试。一旦我们有一个成熟的自动化测试选择(计划在Q3进行),就可以在这里应用它以进一步降低成本。
- 必须通过才能合并PR
- 应该在以下情况下触发：
- PR准备好合并时
- PR作者需要比
fast-check中的更多测试信号 - 触发方式：
- PR自动合并已启用
- 将
Ready标签添加到PR - 作者在PR上添加
/ready评论
3.Post-merge管道 - 目的:捕获所有错误，使
main分支保持干净并准备发布 - 无论怎样运行所有测试。
- 仅在主分支上运行
- 每隔N次提交运行一次
由于PR作者总是可以标记PR以在需要时运行所有测试，因此CI信号不会有太大变化。此外，pre-merge必须在PR合并之前通过，因此无论如何都会有CI信号。
这种方法的缺点是：
fast-check有时不会提供足够的信号，只有在PR尝试合并时才会捕获错误(这时pre-merge运行)。这可能会导致修复错误的进度稍有延迟。- PR作者需要记住添加
ready标签(如果您是提交者)或在/ready上发表评论，如果来自fast-check的CI信号不足的话。 - 一旦在主分支上检测到故障，可能需要一些额外的工作来确定失败的提交，因为现在不再按提交运行
post-merge了。这可以通过从一个小的N开始来控制。
反馈期
我希望尽快开始工作，因为我们的CI成本很高。
抄送列表
@simon-mo@DarkLight1337@dgoupil@youkaichao@ywang96
其他事项
- 无响应*
8条答案
按热度按时间czq61nw11#
我原则上同意这个观点。对我来说，主要的难点是如何向新的贡献者传达这些信息，尤其是关于手动运行
Pre-merge的部分。首先想到的是引入一个机器人，它可以自动在 PR 上发表评论，以通知他们这一点。7rfyedvj2#
介绍一个自动在PR上发表评论的机器人，以通知他们这个情况。
是的，我同意。我们可以这样做，或者在
fast-check运行时在Buildkite UI中放置一个信息横幅(类似于我们在性能基准测试中使用的横幅),内容大致为“这只是部分测试。如果你想运行全部测试，请回到你的PR并添加标签或评论准备......”。owfi6suc3#
请注意，PyTorch有一个合并机器人@pytorchmergebot,只有它才能进行合并。
r7knjye24#
在PR被具有写权限的人批准后，任何人都可以调用@pytorchmergebot来触发一个合并CI,如果CI通过则进行合并。
kpbwa7wx5#
我认为我们可以使用Github auto-merge,但是具有写入权限的人不仅需要批准，还需要自己启用自动合并。使用PyTorchMergeBot有什么特定的优势吗？
nsc4cvqm6#
使用PyTorchMergeBot有什么具体优势吗？
我不知道。这只是为了提供信息，仅供参考 :)
a5g8bdjr7#
是否需要额外的努力来添加按需运行较小测试子集的快捷方式？例如，通过注解
/test-lora只运行 lora 测试。qvtsj1bj8#
是否需要额外的努力来添加按需运行较小测试子集的快捷方式？例如，在
/test-lora上添加注解以仅运行 lora 测试。我认为如果我们只是在 PR 上添加
lora标签，那么fast-check就可以在其他快速测试之上运行 lora 测试。另一个选择是将fast-check中的所有测试(除了快速测试)都设置为可运行，作者只需点击解除阻止即可运行。可能需要一些额外的工作才能实现这一点。