Gitlab CI/CD-【Maven 历险篇 - 2】

问题的场景描述

最近刚把所有的微服务从 Jenkins 迁移到 Gitlab 上，又恰巧碰到集成测试高峰，各个微服务修复 Bug 后，频繁进行【提交->发布->测试】这个过程，本来还能愉快地进行操作，差不多下午16点左右，杯具发生了！！所有微服务在 Gitlab 上执行 Run Pipeline 发布的时候，全都报错，如下图：

问题的排查过程

提示信息很清晰“no space left on device”空间不足，由于我的 Gitlab 是默认安装（自己给自己个儿挖了一个大坑），安装目录所在的磁盘空间很有限，导致了该问题提前发生（注：即使安装的时候指定一个空间较大的磁盘，如果没有合理的配置，空间不足的问题依旧会发生，早晚而已）！依据使用 Jenkins 的经验，猜测可能是 Gitlab 在 CI/CD 的过程中生成了一些过程文件，且该过程文件没有被设置合理的清理策略，导致越积越多，最终爆发！！！猜测的到底对不对呢？！经过排查，发现 gitlab-ci.yml 文件中 stage:package 阶段的有这样一个设置，如下图：

这里要先插播介绍一下 artifacts，TA 是用来干啥的呢？！

将当前阶段（例如：stage:package）某个过程产物（例如：mvn install 生成的 Jar 包）保存一定期限，以供后续阶段使用（以本例为例，stage:package 阶段生成的 XXXX.jar
将会被后续的 stage:build 阶段用来创建一个 image 并 push 到私有镜像仓库中）

这下问题就清晰了，“expire_in: 1 day”不用解释太多了吧，意思就是 mvn install 生成的 Jar 包要保存 1 天，结合“问题的场景描述”，爆发式使用 Gitlab 导致 Jar 包激增，再结合自己个儿挖的大坑（默认安装Gitlab，安装目录磁盘空间太小），导致最终空间不足，整个 Gitlab 的崩溃！！！

问题的解决方案

解决方案分两步：

1. 迁移 Gitlab
2. 调整 gitlab-ci.yml 中 package.artifacts.expire_in 值，如下图：