Nothing in the CRD or in the rendered config.toml can configure [runners.cache]. RunnerConfig in config/config.go has no cache field, api/v1beta2 has no cache types, and there is no raw config.toml passthrough to work around it, so a runner cannot be pointed at S3, GCS or Azure at all.
The effect is worse than a missing feature: cache: in .gitlab-ci.yml looks like it is configured but never restores anything, because with the kubernetes executor the local cache directory lives in the build pod and dies with it. Anyone with a dependency install step hits this on day one.
What would need modelling is the [runners.cache] table (Type, Path, Shared, MaxUploadedArchiveSize) plus one sub-table per backend. S3 alone covers AWS, MinIO, Ceph RGW and R2, so shipping that first and adding gcs and azure later is probably the right split.
[runners.cache]
Type = "s3"
Path = "runner-cache"
Shared = true
[runners.cache.s3]
ServerAddress = "s3.amazonaws.com"
BucketName = "runners-cache"
BucketLocation = "eu-west-1"
AuthenticationType = "iam"Open questions for the evaluation:
- Credentials should reuse the existing token-source shape (value or secret_key_ref) rather than being inline only, since AccessKey, SecretKey, AccountKey and PrivateKey all land in the rendered config secret. Does a secret_key_ref change have to roll the deployment the way the CA source does?
- Credential-free paths: s3 has AuthenticationType = "iam" and gcs falls back to application default credentials. The build pod identity is already settable through executor_config.service_account, so check whether IRSA or Workload Identity works end to end with only Type and BucketName set. If it does, that is the path to document first and keys become the fallback.
- Placement: one cache block on Runner.spec and MultiRunnerSpec shared by every entry, or per entry? Runners sharing a bucket need distinct Path prefixes, and Shared changes the key layout.
- Validation: CEL should reject more than one backend sub-table, and reject a sub-table that does not match Type.
- An in-cluster MinIO over plain http needs Insecure, which is worth an e2e fixture in kind rather than a sentence in the docs.
Done when there is a decision on scope and placement, a CRD sketch, and either an implementation issue or a written refusal. Either way it needs a line in the limitations docs, because right now the gap is silent.
Nothing in the CRD or in the rendered config.toml can configure
[runners.cache]. RunnerConfig in config/config.go has no cache field, api/v1beta2 has no cache types, and there is no raw config.toml passthrough to work around it, so a runner cannot be pointed at S3, GCS or Azure at all.The effect is worse than a missing feature:
cache:in .gitlab-ci.yml looks like it is configured but never restores anything, because with the kubernetes executor the local cache directory lives in the build pod and dies with it. Anyone with a dependency install step hits this on day one.What would need modelling is the
[runners.cache]table (Type, Path, Shared, MaxUploadedArchiveSize) plus one sub-table per backend. S3 alone covers AWS, MinIO, Ceph RGW and R2, so shipping that first and adding gcs and azure later is probably the right split.Open questions for the evaluation:
Done when there is a decision on scope and placement, a CRD sketch, and either an implementation issue or a written refusal. Either way it needs a line in the limitations docs, because right now the gap is silent.