让 Gitlab Runner 使用 node_modules 作为工件而不是在缓存中

Question

根据GitLab 缓存与工件的文档，应该将其node_modules存储为缓存而不是工件。这样做的问题是，如果有多个运行程序，并且与创建“构建”的运行程序不同，那么缓存 ( node_modules) 将不存在，这将导致 GitLab CI 随机失败（如果同一个运行程序碰巧执行了以下操作）其余的工作就会成功）。

我可以做到这一点，这样一切都可以在一项工作中完成，但是一旦我必须进行部署，这个问题就会再次出现。另一种选择是对其进行标记，以便只有一个特定的跑步者完成这项工作，但我觉得这很慢。

经过研究，我意识到我可以将其作为工件而不是缓存放入node_modules，无论哪个运行程序运行该作业，它都会被拾取，但我找不到任何关于这是否不好的文档。

node_modules那么作为神器放起来可以吗？如果是这样，为什么人们通常不会将其作为工件（假设他们添加了过期时间）？

Answer 1

简而言之，您可以随心所欲地使用该工具。您绝对可以使用node_modules 的工件。然而，有一种方法可以让缓存也发挥作用。

默认情况下，当运行程序缓存文件或目录时，它会将其本地存储在运行该运行程序的主机上（这就是它在其他运行程序上不可用的原因）。但是，在运行程序配置中，您可以更改此设置以将缓存对象存储在 AWS S3 或类似 S3 的存储库（如 Minio）中。如果所有运行程序都以这种方式配置，或者至少有 2 个运行程序，那么这些运行程序也可以使用相同的缓存项。

您可以在此处阅读有关运行程序的缓存配置选项的信息：​​https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscache-section

您可以在这里阅读有关 Minio（一种提供 S3 API 接口的开源存储解决方案）的信息： https: //docs.min.io/