GitLab CI制品管理：3个必备技巧

▌ 技术引导
GitLab CI制品管理这条路我走得不轻，踩过坑也摔过跤。你要是真想把CI/CD玩明白，这三个技巧必须掌握，不然你每天都在重复犯错。第一，用`artifacts`时记住必须设置`expire_in`，不然旧的制品会撑爆你的存储，我亲测过，30天没清理干净，硬盘直接告急。第二，`rules`和`only`别混用，否则你永远猜不到CI会跑哪台机器，有一次我因为这个，跑了三遍才发现其实`rules`才是真凶。第三，别忘了`cache`，它能帮你省下成千上万的构建时间，但配置不好会把缓存当垃圾扔掉。这三个点，直接决定你是否能高效管理制品，别问，问就是我用过、踩过、修过。

▌ 技术参考
GitLab CI制品管理是持续集成中不可忽视的一环，核心在于如何高效地存储、传输和清理构建产物。制品（artifacts）主要通过`artifacts`关键字定义，通常用于保存测试报告、编译产物、镜像等。在`artifacts`中设置`paths`指明需要保留的文件路径，同时添加`expire_in`参数控制存储时长，单位为秒。例如，`expire_in: 3600000`代表制品在3600000秒（即400天）后自动删除。这个配置可以避免存储空间被无用文件填满，是我团队在生产环境中强制要求的，否则你的CI管道会像黑洞一样吞噬所有资源。

GitLab CI的制品管理依赖于内置的制品存储系统，每个项目都会有一个独立的存储空间。默认情况下，制品存储在项目的`/artifacts`目录下，可通过Web界面查看和下载。如果你需要将制品上传到第三方存储（如AWS S3或MinIO），必须在`.gitlab-ci.yml`中配置`artifacts`的`storage`参数。例如，`storage: s3`会将制品存储到配置好的S3桶中，同时需要在项目设置中启用相关权限。这种做法在我们多个项目中验证过，尤其是需要跨团队共享制品的场景，非常可靠。

在实际操作中，制品管理的关键是配置`artifacts`的`paths`和`name`。`paths`决定了哪些文件会被打包上传，而`name`可以让制品更清晰地标识出来。比如，`name: "build-$CI_COMMIT_REF_NAME"`会根据分支名生成唯一的制品名称。这样做的好处是后续查找和引用更方便，尤其在多分支并行构建时。此外，如果你希望CI在失败后仍保留制品，可以在`artifacts`中添加`when: always`参数，这在调试和排查问题时非常有用。我经历过一次因为没这个配置，关键日志直接被清理了，浪费了整整一天时间。

制品缓存（cache）是提升构建效率的杀手锏，但它的配置非常讲究。GitLab CI支持两种缓存方式：`cache`和`artifacts`。`cache`更适合保存依赖库、编译产物等，而`artifacts`更适合保存最终输出。使用`cache`时，需要指定`key`和`paths`。例如，`key: "dependencies-$CI_COMMIT_REF_NAME"`可以让不同分支使用不同的缓存，避免冲突。同时，`paths`要精确匹配缓存目录，否则缓存可能无法命中。我曾经因为误写路径，导致缓存每次都重新拉取，构建时间翻倍，教训非常深刻。

如果你使用`rules`来控制CI的运行条件，一定要避免与`only`混用。`rules`是更灵活、更推荐的条件控制方式，但它的行为与`only`有些微妙的不同。比如，在`rules`中使用`if: $CI_MERGE_REQUEST_ID`来触发特定流程，这是正确的做法，但如果你在同一个job中同时写`only: branches`和`rules`，可能会出现逻辑冲突，导致job执行结果不符合预期。我之前在某个项目中，因为这样写，导致某些分支的制品被错误地保留，最终引发了存储占用过高的问题。必须明确区分开，否则你将陷入难以调试的境地。

制品的依赖管理非常重要，尤其是在多阶段构建的场景。比如，使用`dependencies`关键字来指定需要从制品缓存中获取的文件。这样可以避免重复下载，显著提升构建速度。我见过一些项目在`dependencies`中误写路径，导致缓存无法命中，反而增加了构建时间。正确的做法是将依赖文件的路径明确写入`dependencies`，例如：`dependencies: - "build-cache-$CI_COMMIT_REF_NAME"`。这个配置不仅节省时间，还能减少网络流量，对大规模项目尤为关键。

制品的版本控制是另一个容易忽视但至关重要的点。GitLab CI支持通过`refs`来指定制品的版本，比如`refs: - "v1.0.0"`。这样做的好处是你可以精确管理哪些制品是稳定的，哪些是测试性的。我在一个项目中因为没有设置`refs`，导致每次构建都会覆盖之前的制品，最终出现版本混乱。后来改用`refs`配合`job_name`，构建的制品就能以明确的版本号存在，避免了后续的版本冲突问题。这种配置方式需要在`artifacts`中显式声明，否则不会生效。

制品的清理策略直接影响CI的运行成本。GitLab默认会清理超过30天的制品，但你可以通过`expire_in`参数进一步优化。例如，`expire_in: 604800`代表一周后自动删除制品，适用于临时构建或调试环境。对于长期保留的制品，可以使用`keep_time`参数设置保留时长，但注意这个参数只针对`artifacts`，不能用于`cache`。我以前在某个项目中因为误用了`keep_time`，导致存储空间被无限占用，差点触发告警。现在必须严格区分这两个参数的用途，确保资源使用合理。

制品管理的一个常见痛点是网络传输效率。如果你的制品体积庞大，一定要考虑使用`storage: s3`或`storage: gcs`等外部存储，而不是依赖GitLab的默认存储。默认存储虽然简单，但传输速度慢、成本高，尤其在跨区域部署时更是问题。我曾在一个海外项目中，因为误用了默认存储，导致制品传输耗时超过30分钟，严重影响部署效率。后来改用AWS S3，传输时间缩短到不到5分钟，整体构建效率提升了40%以上。这种优化方案适用于大规模项目或分布式部署。

制品的依赖关系管理需要全局视角。如果你在多个CI pipeline中使用相同的缓存策略，最好在父级CI中统一管理。例如，使用`rules`中的`if`条件来判断是否缓存依赖，而不是在每个job中重复配置。这样能减少配置冗余，同时提高可维护性。我之前在某个项目中，每个job都单独配置了缓存，结果在构建过程中缓存策略不一致，导致某些依赖无法正确加载。后来统一配置后，问题迎刃而解，构建过程也更可控。

制品的命名策略会影响你后续的维护效率。建议使用`name`配合`refs`来生成唯一的制品标识，例如：`name: "build-$CI_COMMIT_REF_NAME-$CI_COMMIT_SHA"`。这样每个构建都会产生一个唯一的制品名称，方便追溯和回滚。我之前在某个项目中，因为没有使用`CI_COMMIT_SHA`，导致同一分支的不同构建结果混在一起，最终花了大量时间去定位错误。现在所有项目都强制使用这种命名方式，管理起来更清晰。

在某些情况下，使用`artifacts`可能会导致构建耗时增加，但这是必要的成本。例如，当你的项目需要在多个CI阶段使用相同的制品时，配置`artifacts`是必须的。不过要注意，不要在每个阶段都打包所有文件，而是只保留你需要的。我见过一些项目误将整个项目目录打包上传，结果构建时间翻倍，存储成本飙升。正确的做法是明确指定`paths`，只保留关键文件，避免不必要的资源消耗。

制品管理的另一个关键点是权限控制。如果你将制品上传到第三方存储，必须确保CI流水线有正确的访问权限。例如，在AWS S3中，需要配置`access_key_id`和`secret_access_key`作为环境变量，否则无法上传。我之前在某个项目中因为漏掉了这些参数，导致CI一直报权限错误，最终构建失败。后来通过在`before_script`中显式设置这些变量，解决了问题，也避免了后续的权限混乱。

如果你的项目需要跨环境（如dev、test、prod）共享制品，可以使用`artifacts`的`paths`配合`refs`来实现。例如，在`test`阶段生成的制品，可以在`prod`阶段通过`only`或`rules`来引用。我之前在某个项目中，因为没有正确配置`refs`，导致测试环境的制品被误用到生产环境，最终引发严重问题。后来通过在`artifacts`中设置`refs`，确保不同环境的制品清晰分离，避免了这种风险。

制品的引用方式也有讲究，特别是在多阶段构建时。你可以使用`dependencies`关键字来指定需要从哪个job获取制品，例如：`dependencies: - "build"`。这样做的好处是确保后续阶段使用的是最新的制品，但必须注意依赖关系的顺序。我之前在某个项目中，因为依赖顺序错误，导致后续阶段找不到所需的制品，最终构建失败。后来在`dependencies`中显式指定顺序，问题得以解决。这种场景在微服务架构中尤为常见，需特别留意。

制品管理的最终目标是平衡效率与成本，而不是一味追求速度。比如，使用`cache`可以提升构建性能，但必须控制缓存规模。当缓存体积超过10GB时，建议使用`storage: s3`来避免本地存储的瓶颈。我在一个项目中因为忽视了缓存大小，最终导致CI机器磁盘爆满，系统自动关机。后来改用外部存储后，问题彻底解决，构建也更稳定。这种经验值得所有CI工程师铭记。