artifacts 和 cache 是两样东西

一句话总结

artifacts因为是跨越杂和杂之间的产出物，如果没有的话，后杂必须失败才能正确，cache即使不是在执行和执行之间节省时间的临时资产，所有杂事都必须全部处理到位。

为什么需要这个？

两者看起来都像“指定目录后被保存在某个地方，之后再回来”。所以一开始什么都用，过了一段时间就发生了两种情况。

像使用输出结果一样使用缓存的团队有一天会分发一个空的目录。缓存不是保证，而是优化，所以如果运行者变更或过期，就会只是空着，这时管道不会失败，没有任何东西的状态下安静地成功。相反，像使用输出结果一样使用缓存的团队会收到存储库容量警告。因为没有设定过期的艺术品会在每次提交时堆积起来。

怎么行动

artifacts在任务结束时将指定的路径上传到GitLab服务器。然后在后续任务开始时下载。这里重要的就是谁下载，因为默认值是“全部前阶段”，所以如果没有任何设置，即使不使用发布任务，也会下载所有测试报告。这就是管道变慢的常见原因。

缩小接收方的方法是needs的较长的形式。needs而不是字符串列表{job: build-app, artifacts: true}用形式的话，可以选择是否按杂志分开接收。只要等顺序，对于不需要文件的杂志artifacts: false明确。还有expire_in不是选择，实际上是必须的。只保留成为回溯对象的发布成果，其余的只保留几天。

cache不一样。抓取开始时下载适合键的压缩文件解压，结束时重新上传。因为都是优化，所以即使失败也继续抓取。所以缓存设计的核心不是放什么，而是用什么来做键。

如果把键固定为字符串，即使依赖性发生变化，也会继续使用相同的键，从而携带旧的缓存。因此，将锁文件的哈希值放入键中。key: {files: [requirements.txt]}像这样使用的话，当那个文件发生变化时，键会自动改变，缓存会自动失效。这里policy加上的话再省一次钱。只要做一份来拿现金的杂事。pull-push留为，剩下的消费者pull这样一来，每次消费者看完时，重新压缩相同内容的时间就会消失一整段。

最后，两个列表不能重叠。如果把相同的目录作为副制品或缓存进行管理，没有人知道哪个是最新的，这种混乱很难重现。

在现场相遇的样子

与缓存相关的事故中最危险的不是性能，而是信任。如果从叉中传来的合并请求在缓存中植入恶意依赖性，之后的构建将将该缓存直接使用。由于被称为缓存注入的问题，超越信任界限的缓存会分离范围。

容量方面也是现实的限制。缓存存储空间有限制，超过了就会从旧的开始被挤出来。所以如果每次提交时过度细分键来创建新的缓存，缓存之间就会互相推开，从而降低命中率。键应该以重复使用单位来控制。

下次实习要做的事情

到现在为止读到的内容直接用一张设置文件堆起来。从舞台和第一场比赛开始，到隐藏比赛和extends，needs制作DAG的，rules的分支条件和手动批准，artifacts哇cache分为八个阶段进行。评分不是用眼睛浏览文件，而是用YAML解析器读取文件来确认结构。最后一个阶段是直接编写管道解释器，即使在第一次看到的设置中，也能计算出抓在第几波浪中出发。needs抓住循环。