如何解决让 Gitlab Runner 使用 node_modules 作为工件而不是缓存
根据 GitLab Documentation for cache vs artifacts,node_modules
应该存储为缓存而不是工件。这样做的问题是,如果有多个运行器,并且与创建“构建”的运行器不同的运行器获取作业,则缓存 (node_modules
) 将不存在,这将使 GitLab CI 随机失败(如果相同runner 碰巧完成了其余的工作,然后它就会成功)。
我可以做到一切都在一项工作中完成,但是一旦我必须进行部署,这个问题就会再次发生。另一种选择是标记它,以便只有一个特定的跑步者完成这项工作,但我觉得这很慢。
经过研究后,我意识到我可以将 node_modules
作为工件而不是缓存放入,无论哪个跑步者运行该作业,它都会被拾取,但我找不到任何关于这是否不好的文档与否。
那么把node_modules
当成神器可以吗?如果是这样,为什么人们通常不把它当作神器(假设他们添加了过期时间)?
解决方法
这里的简短回答是,您可以随意使用该工具。您绝对可以将工件用于 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/
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。