如何清理本地GitLab Runner缓存？寻求更优实现方案

核心结论 #

采用Shell执行器并使用本地缓存的GitLab Runner没有内置的自动缓存清理机制，默认不会主动删除分支合并后失效的缓存文件，长期运行必然导致磁盘占用过高。

更优的清理方案 #

1. 利用Runner配置的cleanup_exec脚本

在GitLab Runner的config.toml配置文件中，通过cleanup_exec指定一个清理脚本，Runner会在每个作业执行完成后自动调用该脚本，实现缓存的周期性清理。

• 配置示例（config.toml）：

  [[runners]]
    name = "your-runner-name"
    executor = "shell"
    # 其他配置...
    cleanup_exec = "/opt/gitlab-runner/scripts/cleanup-cache.sh"
  

• 清理脚本示例（cleanup-cache.sh）：

  #!/bin/bash
  # 指定Runner本地缓存的根目录
  CACHE_ROOT="/path/to/gitlab-runner/cache"
  
  # 删除14天未修改的缓存文件
  find "$CACHE_ROOT" -type f -mtime +14 -delete
  # 清理空目录
  find "$CACHE_ROOT" -type d -empty -delete
  

• 优势：与Runner的作业生命周期绑定，无需依赖流水线资源，覆盖该Runner处理的所有仓库缓存，逻辑更贴合Runner的运行机制。

2. 机器本地部署独立定时任务（Cron）

直接在Runner所在的服务器上配置Cron定时任务，独立于GitLab流水线执行缓存清理，完全避免占用流水线资源。

• 配置步骤：

  1. 创建清理脚本（同上面的cleanup-cache.sh）并赋予执行权限：chmod +x /opt/gitlab-runner/scripts/cleanup-cache.sh
  2. 编辑Cron任务：crontab -e
  3. 添加定时规则（示例为每周日凌晨0点执行）：

     0 0 * * 0 /opt/gitlab-runner/scripts/cleanup-cache.sh
     

• 优势：完全独立于GitLab生态，不会受仓库状态影响，适合管理多仓库缓存的场景，资源开销更低。

3. 优化缓存策略（从源头减少堆积）

• 给缓存Key添加更精细的标识（比如结合项目ID、分支名和依赖版本），避免不同项目/分支的缓存互相干扰，同时减少无效缓存的产生。
• 分支合并后，可在合并流水线中添加一步清理对应分支缓存的操作（适合需要即时清理的场景，但需手动维护逻辑）。

对比当前定时流水线方案的问题 #

你当前使用的仓库级定时流水线清理方案，确实存在以下不足：

• 属于单个仓库的流水线，无法覆盖Runner处理的所有其他仓库，管理分散。
• 占用流水线资源，若该仓库停用，清理任务也会中断。
• 本质上是“借用人造流水线”完成系统级的缓存清理，逻辑不够合理。

推荐方案优先级 #

优先选择Runner的cleanup_exec脚本或服务器本地Cron任务，这两种方案更符合缓存管理的职责划分，运行更稳定高效。

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