Support for Cache with GCS
In GitLab Runner 11.3, we will see the introduction of [runners.cache.gcs] settingsgroup for the use of GCS as an alternate caching location to S3. Investigation of the behavioral changes need for this will be need before implementation. Specifically, how to implement CredentialsFile
's setting, as this provides the JSON key file which must be presented in the filesystem.
In charts/gitlab's registry chart, we addressed this by mounting an additional key from the secret.
The method currently used within this chart is based on the expectation of S3, using only accesskey
and secretkey
items from the provided .Values.runners.cache.secretName
. When adding this new configuration for GCS, we will need to be wary of breaking changes surrounding the .Values.runners.cache
property map. At the moment, most of the properties are effectively named after cacheType: s3
value, such as .Values.runners.cache.s3ServerAddress
, which thankfully provides an easier path forward than had they not been prefixed with s3
.
- Specifically examine the method of populating the
init-runner-secrets
Volume, and which items of the key are mapped to what files in the deployment. - Examine the _cache_s3.tpl, and either restructure this to include GCS, or implement a second
_cache_gcs.tpl
, and have this integrated into _env_vars.tpl based on.Values.runners.cache.cacheType
's value. - Document these changes and their handling.