gitlab ci artifacts留存周期配置不当是对象存储空间暴满的最常见原因，其依赖后台定时任务清理而非实时删除，需检查expire_in配置、清理服务运行状态及滞留文件并建立监控闭环。
GitLab CI 的 artifacts 留存周期配置不当，是导致对象存储空间（如 /var/opt/gitlab/gitlab-rails/shared/artifacts/）暴满的最常见原因。它不直接删文件，而是靠后台定时任务清理——所以“设了 expire_in 却没释放空间”，往往不是配置没生效，而是清理链路卡在了某一个环节。
一、快速定位是否真是 artifacts 导致暴满
登录 GitLab 服务器后，先确认磁盘占用大户：
- 运行
du -sh /var/opt/gitlab/gitlab-rails/shared/artifacts/* | sort -hr | head -10，看 artifacts 目录是否占主导（常达几十~几百 GB） - 对比其他高危目录：
/var/opt/gitlab/gitlab-rails/shared/lfs-objects（LFS）、/var/opt/gitlab/backups（备份）、/var/log/gitlab（日志） - 若 artifacts 占比超 60%，基本可锁定为根因
二、检查 .gitlab-ci.yml 中 expire_in 是否真正生效
expire_in 必须显式写在每个 job 的 artifacts 块里，且单位明确，否则默认按秒计算（极易误配成“1 天 = 1 秒”）：
- 错误写法：
expire_in: 7→ 实际只保留 7 秒 - 正确写法：
expire_in: 7 days或expire_in: 2 weeks - 仅对 成功 job 生效；失败 job 需加
when: always才可能存 artifact - 路径必须存在：
paths: - dist/要求构建脚本确实生成了dist/目录
三、验证后台清理服务是否正常运行
GitLab 不靠系统 crontab，而是通过内置 gitlab-rails 定时任务每小时扫描过期 artifacts。需确认它在工作：
- 执行
sudo gitlab-ctl tail cron，查找类似Deleting expired job artifacts...的日志（每小时一次） - 若无记录，检查 GitLab 版本：GitLab ≥ 15.0 基本稳定；低于 14.0 可能需手动启用或升级
- 临时触发一次清理调试：
sudo gitlab-rails runner "Ci::Cleanup::ExpiredArtifactsService.new.execute"
四、清理已过期但滞留的 artifacts（应急+治理）
有时过期文件未被及时扫到，可用安全命令补救：
- 预览将删哪些文件（只读，不删）：
sudo gitlab-rake gitlab:cleanup:orphan_job_artifact_files - 执行真实清理：
sudo gitlab-rake gitlab:cleanup:orphan_job_artifact_files DRY_RUN=false - 补充检查：查已过期但未清理的数量
sudo gitlab-rails runner "Ci::JobArtifact.expired.count"，若结果远大于 0，说明清理滞后
治理关键在于“配置 + 监控 + 定期验证”闭环。建议每周用 expired.count 检查一次，避免积压演变成磁盘告警。
