GitLab Runner设置concurrent=6后缓存与Linter异常求助

一、先排查Linter执行失败的关联问题 #

• 先验证Linter失败是否和并发冲突有关：检查.gitlab-ci.yml里Linter作业的缓存、工作目录配置，是否存在多作业同时读写本地文件的竞争场景？比如有没有指定独立工作空间，是否依赖了未隔离的本地资源。
• 临时将concurrent改回1，单独运行Linter作业，若恢复正常，说明是并发下的资源竞争问题。可以给Linter作业添加resource_group限制同一时间仅运行一个实例，或者配置作业使用独立缓存路径。
• 查看Linter的具体报错日志，确认是文件缺失、权限问题还是依赖未安装。如果是依赖问题，大概率是缓存未生效导致重复安装失败，优先解决缓存问题后再回头验证。

二、解决缓存异常与作业间缓存共享问题 #

1. 本地缓存的并发冲突修正 #

默认本地缓存模式下，多并发作业会同时读写同一缓存目录，极易导致缓存损坏或读取失败：

• 修改config.toml，为每个runner实例指定独立的本地缓存路径，示例：

[[runners]]
  name = "Concurrent Runner 1"
  url = "你的GitLab实例地址"
  token = "你的Runner令牌"
  executor = "shell"
  [runners.cache]
    Path = "/tmp/gitlab-runner-cache-1"

[[runners]]
  name = "Concurrent Runner 2"
  url = "你的GitLab实例地址"
  token = "你的Runner令牌"
  executor = "shell"
  [runners.cache]
    Path = "/tmp/gitlab-runner-cache-2"

复制足够多的[[runners]]块（对应concurrent=6），每个块配置不同的缓存路径，避免读写冲突。

• 若使用docker executor，确保作业容器完全隔离，缓存挂载路径不重叠，或直接切换到分布式缓存。

2. 分布式缓存服务器搭建修正 #

如果之前搭建Redis/MinIO等缓存服务器遇阻，按以下步骤排查：

• Redis缓存配置：
  在config.toml的全局或runner块中添加：

  [runners.cache]
    Type = "redis"
    Path = "cache"
    Shared = true
    [runners.cache.redis]
      Address = "redis服务器地址:6379"
      Password = ""
      DB = 0
  

  重点开启Shared = true，确保所有作业共享缓存。同时验证Redis服务正常、Runner机器能连通Redis端口、无防火墙拦截。
• MinIO（S3兼容）缓存配置：

  [runners.cache]
    Type = "s3"
    Path = "cache"
    Shared = true
    [runners.cache.s3]
      ServerAddress = "MinIO服务器地址:9000"
      AccessKey = "你的AccessKey"
      SecretKey = "你的SecretKey"
      BucketName = "gitlab-cache"
      Insecure = true # 若使用HTTP访问需开启
  

  确保MinIO桶已创建、权限配置正确，Runner机器能访问MinIO地址，必须开启Shared = true才能实现作业间缓存共享。
• 配置完成后测试：运行一个生成缓存的作业，再启动另一个依赖缓存的作业，检查缓存是否正常读取；同时查看Runner日志（gitlab-runner logs）中的缓存相关输出，排查连接、权限类错误。

三、并发配置的优化建议 #

• 确认构建机器资源（CPU、内存）能支撑6个并发作业，避免资源耗尽导致作业失败。比如每个作业占用1核2G内存，6个作业至少需要6核12G内存，可根据实际负载调整concurrent数值。
• 在.gitlab-ci.yml中给不同类型作业设置tags，分配到专属Runner（如Linter专属Runner、构建专属Runner），避免不同类型作业抢占资源。
• 给资源密集型作业设置timeout和resource_group，防止单个作业长时间占用资源影响整体并发效率。

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