OpenShift 4+自托管GitLab部署to-be-continuous时流水线故障求助

问题1：GitLab Runner抛出「Could not create cache adapter」报错 #

• 排查方向：优先检查GitLab Runner的缓存配置，OpenShift环境下Runner默认以随机非root UID运行，大概率是缓存存储路径权限不足或配置缺失
• 解决步骤：
  1. 查看Runner的config.toml配置中[runners.cache]段，若使用本地PVC存储缓存，需给缓存挂载路径配置fsGroup，或设置目录权限为777，确保运行用户可读写
  2. 若使用S3/对象存储作为缓存后端，确认访问密钥、端点地址、桶名配置正确，且Runner所在集群可正常访问存储服务

问题2：写入/etc/ssl/certs/ca-certificates.crt触发Permission denied报错 #

• 排查方向：to-be-continuous流水线默认会在运行时将自定义CA注入系统证书池，但OpenShift运行CI Job的容器默认无root权限，无法修改/etc目录下的文件
• 解决步骤：
  1. 优先选择预构建镜像方案：将自托管GitLab的CA证书提前预置到所有CI用到的基础镜像的/etc/ssl/certs/路径下，避免运行时写入
  2. 若不便修改基础镜像，可在GitLab组/项目CI变量中新增TBC_CA_CERTIFICATES_PATH，值设为当前用户可写的路径如/tmp/ca-certificates.crt，同时配置对应工具的证书读取环境变量指向该路径
  3. 不推荐给Job绑定anyuid权限的方案，会带来安全风险

问题3：kaniko任务推送Docker Hub镜像权限失败 #

• 排查方向：tracking仓库默认配置的镜像推送目标是to-be-continuous官方的Docker Hub仓库，你的自托管环境没有官方仓库的推送权限
• 解决步骤：
  1. 在to-be-continuous根组或tracking项目的CI变量中配置DOCKER_REGISTRY为你的私有镜像仓库地址（如OpenShift内置镜像仓库、自托管Harbor等）
  2. 新增DOCKER_REGISTRY_USER和DOCKER_REGISTRY_PASSWORD变量，填入私有镜像仓库的合法访问凭据
  3. 若不需要保存构建的snapshot镜像，可直接修改tracking仓库的CI配置，移除kaniko任务的镜像推送步骤

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