问题描述
我正在将gitlab 10.4.3与gitlab-runner 10.4.0一起作为kubernetes部署与kubernetes Runner和用于缓存的minio服务器一起运行.我根据 gitlab文档进行安装
I'm running gitlab 10.4.3 with gitlab-runner 10.4.0 as a kubernetes deployment with kubernetes runner and a minio-server for caching. I installed it according to the gitlab docs.
将适当的设置添加到.gitlab-ci.yml
-文件时,一切都能按预期使用缓存:
Everything worked with the cache as expected, when adding the appropriate settings to the .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
管道输出确实第一次填充了缓存,并且随后在同一分支上的后续运行正确地拉入并推送了缓存:
The pipeline output did fill the cache the first time and subsequent runs on the same branch correctly pulled and pushed the cache:
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只是忽略了设置,只是跳过了检查缓存部分":
However, after some runs it suddenly stopped working - and I do not know why. I've also tried a job-global cache-definition to no avail - it seems that the gitlab-runner is simply ignoring the setting and just skips the "Checking cache part":
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具有适当的设置:
My gitlab-runner config.toml has the appropriate settings:
[[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
注意:如果将设置更改为无效的设置,则在跑步者日志中不会收到任何错误消息.
Note: If I change the settings to invalid ones, I do not get any error messages in the runners logs.
可以从跑步者本身和从作业吊舱到达端口:
The port is reachable from the runner itself and from job pods:
$ 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客户端mc
在本地卷和中选中的minio上的存储桶存在.
The bucket on minio exists as checked in the local volume and via the minio client mc
.
gitlab-runner或minio-server的pod的日志中没有错误.
There are no errors in the logs of the pods of gitlab-runner or the minio-server.
这就像.gitlab-ci.yml
的缓存设置被简单地忽略了一样,我对剩下的要检查的东西也一无所知.任何有想法的人吗?
It's just like the cache-settings of the .gitlab-ci.yml
are simply ignored and I'm out of ideas on what's left to check. Anyone with any ideas?
推荐答案
因此,问题在于无效的文档以及对无效cache:keys的无提示忽略.如果分支是例如名为feature/some-new-thing
的结果,"$CI_BUILD_REF_NAME"
的键将导致无效的cache:key包含"/"字符-反过来将使整个cache-section无效,但将被忽略.
So, the problem was an invalid documentation in combination with a silent ignore of invalid cache:keys. If a branch is e.g. named feature/some-new-thing
, the resulting key of "$CI_BUILD_REF_NAME"
would lead to an invalid cache:key containing a "/"-character - which in turn would render the whole cache-section invalid, but which is silently ignored.
相反,只需使用"${CI_BUILD_REF_SLUG}"
,它将包含url-safe-并因此包含cache:key-safe-分支名称的版本:
Instead, just use "${CI_BUILD_REF_SLUG}"
, which will contain an url-safe - and therefore cache:key-safe - version of the branch name:
cache:
key: "${CI_BUILD_REF_SLUG}"
paths:
- node_modules/
错误报告已打开.
这篇关于带有minio服务的kubernetes上的gitlab-ci缓存不再起作用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!