gitlab ci 的 artifacts:expire_in 仅标记过期时间而不直接删除文件，实际清理由后台每小时运行的定时任务执行；需在 .gitlab-ci.yml 中为每个 job 显式配置带单位的 expire_in、确保 gitlab-rails 定时服务启用、必要时用 rails 命令验证或手动触发清理，并可通过管理界面设置全局默认过期策略防遗漏。
GitLab CI 的 artifacts:expire_in 是自动清理过期构建产物的核心机制，但它本身**不直接触发物理删除**，而是标记过期时间，由 GitLab 后台定时任务（每小时运行一次）扫描并清理。在 Linux 系统上正确利用它，关键在于配置 + 确认后台服务就绪 + 必要时辅助干预。
1. 在 .gitlab-ci.yml 中正确设置 expire_in
这是源头控制，必须写在每个会产生制品的 job 里：
-
单位要明确：支持
1 hour、3 days、2 weeks、1 month等自然单位；不写单位默认是秒（易误用，不推荐） -
路径需存在且可访问：
paths指定的必须是作业执行目录下的相对路径，如- dist/、- coverage.xml -
仅对成功作业生效：失败 job 默认不生成 artifacts，除非显式加
when: always
示例：
build:
stage: build
script: npm run build
artifacts:
paths:
- dist/
expire_in: 7 days
2. 确保 GitLab 后台清理服务已启用
Linux 服务器上，GitLab 的 artifacts 清理依赖于内置的 cron 作业（gitlab-rails 定时任务），不是系统 crontab。确认方式：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 登录 GitLab 服务器，执行：
sudo gitlab-ctl tail gitlab-workhorse或查看日志：sudo gitlab-ctl tail cron - 检查是否看到类似
Deleting expired job artifacts...的日志条目（通常每小时一次） - 若无记录，可能是 GitLab 版本较老或配置异常；升级到 GitLab 15.0+ 可基本确保该功能稳定
3. 查看与验证过期状态（运维排查用）
当发现磁盘未如期释放，可快速定位问题：
- 查项目下所有未过期 artifacts 大小：
sudo gitlab-rails runner "Project.find_by_full_path('group/project').ci_job_artifacts.where('artifacts_expire_at > ?', Time.now).sum(:size)" - 查已过期但尚未被清理的 artifacts 数量：
sudo gitlab-rails runner "Ci::JobArtifact.expired.count" - 手动触发一次清理（调试用，非日常操作）：
sudo gitlab-rails runner "Ci::Cleanup::ExpiredArtifactsService.new.execute"
4. 配合全局默认策略防遗漏
即使 job 里没写 expire_in，也可通过 GitLab 管理界面统一兜底：
- 管理员进入：Main menu → Admin → Settings → CI/CD → Continuous Integration and Deployment
- 设置 Default artifacts expiration，例如填
30 days - 该值会作为所有未显式声明
expire_in的 job 的默认过期时间
不复杂但容易忽略：expire_in 是“软标记”，真正删文件靠后台服务。配好 YAML、确认服务跑着、再定期看下磁盘用量趋势，就能稳住 CI 存储水位。
