3

我正在运行带有 gitlab-runner 10.4.0 的 gitlab 10.4.3 作为带有 kubernetes runner 和用于缓存的 minio-server 的 kubernetes 部署。我根据gitlab docs安装了它。

将适当的设置添加到.gitlab-ci.yml-file 时，一切都按预期使用缓存：

build:
  stage: build
  variables:
    GIT_STRATEGY: fetch
  cache:
    key: "$CI_BUILD_REF_NAME"
    paths:
      - node_modules/
  script:
    - compile-templates.sh
    - yarn install
    - yarn run build

管道输出第一次确实填满了缓存，随后在同一分支上的运行正确地拉出并推送了缓存：

Running on gitlab/runner-abcdefg-project-123-concurrent-123456 via gitlab-runner-123456-987654...
Cloning repository for feature/gitlab-cache with git depth set to 1...
Cloning into '/group/project'...
Checking out b1348594 as feature/gitlab-cache...
Skipping Git submodules setup
Checking cache for feature/gitlab-cache...
Downloading cache.zip from http://minio-service:9000/runner/runner/abcdefg/project/123/feature/gitlab-cache 
Successfully extracted cache
$ docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
Login Succeeded
[...snip...]
Creating cache feature/gitlab-cache...
node_modules/: found 26281 matching files
Uploading cache.zip to http://minio-service:9000/runner/runner/abcdefg/project/123/feature/gitlab-cache 
Created cache

然而，经过一些运行它突然停止工作 - 我不知道为什么。我还尝试了作业全局缓存定义但无济于事 - 似乎 gitlab-runner 只是忽略了设置，只是跳过了“检查缓存部分”：

Running on gitlab/runner-abcdefg-project-123-concurrent-123456 via gitlab-runner-123456-987654...
Cloning repository for feature/gitlab-cache with git depth set to 1...
Cloning into '/group/project'...
Checking out b1348594 as feature/gitlab-cache...
Skipping Git submodules setup
$ docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
Login Succeeded
[...snip...]
Job succeeded

我的 gitlab-runner config.toml 具有适当的设置：

[[runners]]
  // ...
  [runners.kubernetes]
  // ...
  [runners.cache]
    Type = "s3"
    // I've also tried http://minio-service:9000 to no avail
    ServerAddress = "minio-service:9000"
    AccessKey = "xxxxxxxxxxxxxxxxxxxxxxxx"
    SecretKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    BucketName = "runner"
    Insecure = true

注意：如果我将设置更改为无效设置，我不会在运行器日志中收到任何错误消息。

该端口可从 runner 本身和作业 pod 访问：

$ curl -s "http://minio-service:9000"
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Access Denied.</Message><Key></Key><BucketName></BucketName><Resource>/</Resource><RequestId>12345</RequestId><HostId>12345</HostId></Error>

minio 上的存储桶存在于本地卷中并通过 minio 客户端检查mc。

gitlab-runner 或 minio-server 的 Pod 的日志中没有错误。

就像.gitlab-ci.yml只是忽略了缓存设置一样，我对剩下的检查内容一无所知。有任何想法的人吗？

4

1 回答 1

2

因此，问题在于无效的文档以及对无效缓存的静默忽略：键。例如，如果一个分支被命名为feature/some-new-thing，则生成的键"$CI_BUILD_REF_NAME"将导致无效的缓存：包含“/”字符的键 - 这反过来会使整个缓存部分无效，但会被静默忽略。

相反，只需使用"${CI_BUILD_REF_SLUG}"，它将包含一个 url-safe - 因此 cache:key-safe - 版本的分支名称：

cache:
  key: "${CI_BUILD_REF_SLUG}"
  paths:
    - node_modules/

已打开错误报告。

于 2018-02-10T15:20:25.110 回答