1. 首页
  2. 问答
  3. [strapi]CI：通过改进纱线安装和缓存来加快 CI 时间（迭代 1 / >30%）

[strapi]CI：通过改进纱线安装和缓存来加快 CI 时间（迭代 1 / >30%）

2024-05-13 834 views
6
  • 使最小测试操作运行大约 +/-12 分钟（而之前为 [25-35] 分钟）。
  • 使完整的测试操作在+/- 55分钟的冷缓存中运行（而在1小时20分/1小时40分的热缓存之前？）
  • 更能适应 npm 中断（在热缓存上）。
  • yarn.lock 更改不会完全使缓存失效（添加和修剪更改的内容）。新的 P/R 通常会从热缓存开始。
  • 减少 github 缓存预算的压力
参考基准 它有什么作用？

尝试缩短 ci 安装时间。

图像

为了使其工作，.yarn/cache/*.zip还应该缓存/恢复。

没有适用于每种用例的单一解决方案，因此我根据经验创建了单独的安装操作。

链接：

要获得快速安装：.yarn/cache++install_state是**/node_modules/理想的选择。

请参阅（来自https://github.com/belgattitude/httpx/actions/runs/4850630708/jobs/8643715240）

图像

  • (1) 必需：yarn 缓存.yarn/cache.zip（即使在锁更改时也可重用）
  • (2) 可选：install_state（锁/操作系统/节点版本更改时无效）
  • (3) 可选：node_modules/**（锁/操作系统/节点版本更改时无效）

由于缓存 node_modules 文件夹在压缩/解压缩时间方面很重（+锁更改/架构/libc 失效...）。有时最好不要启用它。特别是当使用 YARN_COMPRESSION_LEVEL=0 时

但看看您的工作流程，保存所有内容可能是有意义的（以便可以在步骤之间重用）。它在缓存大小和压缩/解压缩方面更重......可能需要尝试这两个选项来获取测量结果（安装时间以及存储/恢复缓存的时间）

我直接在代码中注释

为什么需要它？

并不是真正需要，但尝试一下可能会很有趣。非常适合：落叶树：：回收：

如何测试呢？

CI 应该可以通过，安装缓存应该会带来一些速度提升。

任务列表：

修复警告：Unexpected input(s) 'path', 'key', valid inputs are ['always-auth', 'node-version', 'node-version-file', 'architecture', 'check-latest', 'registry-url', 'scope', 'token', 'cache', 'cache-dependency-path']

belgattitude

回答

7

CLA助理检查
所有提交者都签署了 CLA。

strapi-cla

4

处理测量需要运行 CI。开放讨论

belgattitude

5

另请注意，yarn 4.0.0-rc.43 会带来小的性能提升（我发现最新的 4rc 非常稳定）。

也打开试试。尤其是supportedArchitectures 选项似乎适合这里。如果需要，可以在单独的 P/R 中完成（需要调整操作/缓存键）。

belgattitude

4

只是为了保留一个参考：

测试工作流程 - https://github.com/strapi/strapi/actions/runs/4852553521

图像

图像

图像

我刚刚将 main 合并到这个 PR 中。

@gu-stav 你能再次批准工作流程吗？

我想看看（完整的）热缓存情况会带来什么，并根据我发现的内容进行调整

belgattitude

3

@gu-斯塔夫

如果我没记错的话，因为 nx 可能会隐藏一些差异......

从历史来看，test工作流程一般需要很长时间。

有了这个 P/R，安装时间似乎更快了（两倍或更多？）。

让我做最后一个测试，而不实际保存 node_modules 和 install-state 进行比较。

我稍后会推送，如果您能再次批准那就太好了。

从那里我将进行最后一次测试，我相信这将带来很大的加速。

belgattitude

3

这是最新的运行...没有缓存node_modules

图像

图像

总结...

  • 速度：简单的测试工作流程从 25-35 分钟缩短到 13 分钟（我相信它将“更加”稳定）
  • 稳定性：在热缓存已满的情况下，不会获取任何内容（npm 中断恢复能力强）
  • 缓存使用：与之前相比，操作缓存预算可能增加 30%（保存 node_modules）+我们在 P/R 关闭时丢弃它。 （注意，新的P/R将从最新的主分支缓存开始）

我对下一次迭代有一些想法，但我觉得这是一个好的开始。

belgattitude

3

@gu-stav 让我知道你的想法和评论。对我来说，合并很好，我也可以帮助解决明天可能出现的问题。

belgattitude

4

@belgattitude 您可以更改 .github/filters.yaml 来运行后端和前端吗？如果工作流程发生任何更改可能是个好主意。

Boegie19

3

添加了 EE 标签，因此下次我们运行测试时，它也应该运行 EE 测试

Boegie19

2

@Boegie19我刚刚合并了 main 来触发这个事情。你能批准吗？

belgattitude

7

@belgattitude 不是只有 Strapi 员工才能让我让其中一人来做这件事。另外，请仍然进行我上面要求的更改，以便运行所有测试

Boegie19

0

刚刚意识到 Strapi 上周改变了它的工作方式

Boegie19

9

是的，它没有运行 ee

belgattitude

5

如果我们认为应该将其推进并针对 EE 进行测试，我们可以将其移至内部分支并重新制作 PR。

joshuaellis

0

或者我暂时删除跳过测试？

belgattitude

2

或者我暂时删除跳过测试？

是的还是那个。

joshuaellis

8

这是一个很好的性能提升，从 1 小时 20 分钟缩短到 55 分钟

Boegie19

5

是的，确实如此，那条 55m 处于初始冷启动状态。

安装时间也可能更加恒定。这给出了一个很好的基线

当我查看整个图片时，我发现了更多。我们非常有信心可以轻松缩短 15 分钟。也许稍后，turborepo impl 会找到它的出路。

我猜接下来的迭代

与此同时，我很高兴这能被合并

belgattitude

2

@belgattitude 请注意将 .github/workflows 添加到

我没有得到你要求的东西:)

belgattitude

2

别担心，我应该说得更清楚。

另外，我对这个 PR 更快的 CI 非常满意，所以等待测试是否失败的时间更少，这也应该对解决你的 github 工作拥塞问题有很大帮助

Boegie19

1

只是为了确认您现在明白我在这里问的内容了，对吗？

还是没明白。我在这个分支中有这个文件，它与主分支和另一个分支上的文件相同。

我错过了一些东西，我需要在这个分支上做点什么吗？

请注意将 .github/workflows 添加到

我不明白的是添加工作流程是什么？

belgattitude

4

@belgattitude 基本上我们有 Strapi/.github/filters.yaml 该文件用于过滤器来说明将要运行的内容，您需要添加 Strapi/.github/workflows/* 。到文件，以便它始终运行工作流程更改的所有测试

Boegie19

0

明白了我就去做谢谢

belgattitude

1

嘿伙计们，我的时间很有限，但我想给你们这张照片，因为它对我来说开始有意义

  1. 这次迭代 - 安全更改。带>30%（现在准备好）
  2. 第二次迭代 - >45％yarn.lock修改/压缩级别 - https://github.com/strapi/strapi/pull/16638（可能以天为单位）
  3. 第三次迭代 - > 55% 优化锁定和稳定性。
  4. 第四（可选）重新评估管道/步骤工作流程（deps）以减少所需的安装（当然，如果适用并且基于反馈）
  5. 五 - 尝试与 setup/node 协调并带来功能对等（在https://github.com/actions/setup-node/issues/325中）。我觉得这会对 :decidious_tree: 产生更大的影响:)
  6. 最后一个：当设置/节点稳定时：删除此（几个月）

与此同时，我正在探索减少更多的方法。但有时我必须修补纱线。我尝试找到一种安全的方法来绕过解析/链接阶段。 （我猜是几个月）。非常令人兴奋：在我使用类似设置（更大一点）完成的测试中 - 我可以安装热缓存 20 秒。我的意思是希望到达那里:)

belgattitude

5

@joshuaellis 我也有类似的想法 - 我们是否应该将此 PR 的一些结论作为代码注释添加到操作/工作流程文件中，以使它们与代码位于同一位置？对于贡献者文档，我们也许可以采取更高层次的观点并描述 CI 管道及其总体思路。

gu-stav

 相关问题