GitLab CI跨流水线传递生成文件夹的实现方案及GitLab Pages制品咨询

可行实现总览 #

跨流水线传递生成的业务文件夹，不需要绑定单一技术方案，目前主流可落地的路径包括三类：原生CI组件（Artifacts、Cache）、外部存储对接、基于GitLab API的定制拉取逻辑。

常见疑问解答 #

1. 是否可以仅通过Artifacts实现跨流水线文件传递 #

完全可以。
Artifacts的原生设计目标是同流水线内的作业间文件传递，文件生成后会按照项目配置的留存周期（支持自定义从几小时到永久的留存时长）保存在GitLab服务端。如果需要跨流水线传递文件，上游作业将目标文件夹配置为Artifacts输出后，下游作业可以通过GitLab API或内置命令，拉取留存期内任意历史流水线的指定Artifacts完成文件传输，不需要额外依赖其他组件。
需要注意的是，Artifacts不支持跨流水线的自动级联关联，需要手动指定要拉取的制品来源，没有内置的自动传递能力。

2. 是否只能通过Cache完成该需求 #

远不是只能依赖Cache实现。
Cache的原生设计目标是缓存项目依赖文件、加快作业运行速度，减少重复下载依赖的耗时，本身就不是为跨流水线传递业务生成文件设计的，可靠性、传递可控性都不适合正式的业务文件传递场景。
除Artifacts方案外，还可以通过对接外部对象存储、制品库实现跨流水线文件传递：上游作业将生成的文件夹上传到外部存储，下游流水线直接从对应存储路径拉取文件即可，这种方案的传输稳定性、留存灵活性都远高于Cache。

3. 采用Cache方式是否支持设置缓存过期时间 #

支持。
GitLab CI的Cache配置块中，可通过expire_in参数自定义缓存的自动清理时长，支持分钟、小时、天级别的时间粒度配置，超过设置时长的缓存会被GitLab内置的缓存清理任务自动清除。
需要注意的是，Cache是项目级共享的存储，没有严格的作业/流水线边界隔离，跨流水线传递业务文件时很容易出现缓存被其他作业覆盖、命中率不稳定的问题，不推荐在正式生产流程中使用该方案。

GitLab Pages 作业/流水线间的制品传递方法 #

针对GitLab Pages场景下的静态文件传递需求，可按照传递范围选择对应方案：

• 同流水线内传递：直接使用原生Artifacts能力即可。上游生成静态站点文件的作业，将静态文件输出目录配置为Artifacts路径；Pages作业开启对上游作业的依赖，即可自动获取全部静态文件，后续按照Pages的部署规则，将文件放入作业运行目录下的public文件夹，即可完成站点部署。
• 跨流水线传递：上游生成静态文件的作业将输出目录配置为长留存周期的Artifacts，避免文件被自动清理；下游流水线的Pages作业，在脚本执行阶段调用GitLab内置的制品拉取命令，获取上游留存的静态文件制品，解压到当前作业的public目录下，即可触发Pages的正常部署流程。

注意：Pages部署完成后的站点静态资源本身已经托管在GitLab Pages服务上，不需要将这部分内容再作为跨流水线制品传递，迭代更新站点时仅需传递最新生成的静态文件即可。

内容的提问来源于stack exchange，提问作者ullas kakanadan