Maven 如何仅为运行管道缓存作业结果？

我编写了一个pipline，用Maven构建我的Java应用程序。我的Git存储库中有功能分支和主分支，因此我必须将Maven goal

package

和

deploy

分开。因此，我在管道中创造了两个工作岗位。最后一个作业需要第一个作业的作业结果

我知道我必须缓存工作结果，但我不想

• 将作业结果公开给GitLab UI
• 将其暴露于管道的下一次运行

我尝试了以下解决方案，但没有成功

使用

我接着说：

缓存

.m2/repository

文件夹（存储所有Maven文件的地方）和

target

文件夹（创建应用程序的地方）有助于通过按顺序运行所有Maven阶段来加快流程，因此，如果需要，执行mvn测试将自动运行

mvn compile

但此解决方案在管道之间共享作业结果，请参见：

如果启用了缓存，则默认情况下，从GitLab 9.0开始，它在项目级别的管道和作业之间共享。缓存不会在项目之间共享

而且它不应用于同一管道中的缓存，请参见：

不要使用缓存在阶段之间传递工件，因为它是用来存储编译项目所需的运行时依赖项的：

缓存

：用于存储项目依赖项

缓存用于加速后续管道中给定作业的运行，方法是存储下载的依赖项，这样就不必再次从internet获取它们（如npm包、Go供应商包等），而缓存可以配置为在阶段之间传递中间构建结果，这应该用工件来代替

工件

：用于将在各个阶段之间传递的阶段结果。

工件是由作业生成的文件，这些文件被存储和上传，然后可以被作业在同一管道的后续阶段获取和使用。这些数据在不同的管道中不可用，但可以从UI下载

使用

此解决方案将作业结果公开给GitLab UI，请参阅：

工件将在作业完成后发送到GitLab，并可在GitLab UI中下载

完成管道后，无法使缓存过期，请参阅：

除非提供了单位，否则中的

expire_值是以秒为单位的经过时间

有没有办法只为正在运行的管道缓存作业结果？
在GitLab中，没有办法在作业之间发送构建工件，而这些工件只能在管道运行时保存。这就是GitLab设计CI解决方案的方式

在GitLab中，在作业之间发送构建工件的推荐方法是使用。此功能始终将文件上载到GitLab实例，在这种情况下，它们会调用协调器。在编写时，这些文件可以通过GitLab UI获得。在大多数情况下，这完全是浪费空间，但在极少数情况下，这非常有用，因为您可以下载工件并检查管道损坏的原因

项目成员可以下载这些工件，他们至少是
报告者
，但如果启用了公共管道，每个人都可以查看这些工件。您可以阅读有关权限的更多信息

要不填满硬盘或配额，您应该在

中使用

expire\u。如果你真的不想浪费空间，你可以把它设置为几个小时。但我不建议这样做，因为如果依赖于这些工件的作业失败，您将重试它，如果工件已过期，您将不得不重新启动整个管道。对于中间构建工件，我通常将此时间延长到一周，因为这通常适合我的需要

如果您想使用缓存来保存构建工件，可能是因为您的构建工件很大，需要对其进行优化，那么应该可以使用
CI\u PIPELINE\u ID
作为缓存的键（我还没有测试过这个）：

缓存中的文件应存储在安装runner的位置。如果您确保所有需要这些构建工件的作业都由有权访问此缓存的运行程序执行，那么它应该可以工作

您还可以尝试其他一些预定义的作为缓存密钥的方法。
在管道中的作业之间发送构建工件的正常方法是使用工件。你写道你不想“将作业结果公开给GitLab UI”，这到底意味着什么？构建工件可以在您放入

中的

expire\u时从GitLab UI下载，作业的构建日志也存储在GitLab UI中。这里是否存在某种安全问题？@MrBerta您可以在GitLab UI中浏览和下载作业的工件。这对于中间数据来说至少是不必要的。没有人希望看到这些数据，因此这是在浪费空间和性能。在某些情况下，这可能是一个安全问题，但现在我没有安全问题。没有敏感数据。@MrBerta顺便说一句：文档的一部分建议使用
缓存
，另一部分建议使用
工件
，这也有点让人困惑。这是GitLab的CI体系结构的建立方式。他们希望支持只通过主GitLab实例进行通信的分布式运行程序。这就是为什么所有作业都将工件推送到主实例，而其他作业从这里检索它们。我还认为缓存的工作方式与此相同，它将文件上载到主GitLab实例。关于缓存的想法是能够重用管道所需的外部事物，并且可以在不同管道之间共享。您有非常大的构建工件吗？否则
cache:
  key: ${CI_PIPELINE_ID}