Enable cache on GitLab.com managed Kubernetes gitlab-runner
Problem to solve
Cache is stored at the runner by default. For the GitLab managed Kubernetes gitlab-runner, it will spawn a new container for each job. This means that the cache is effectively not working. There is also no way to configure this runner from the UI, in order to set up another cache storage for the runner
Target audience
-
Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
-
Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
-
Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
-
Devon, DevOps Engineer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#devon-devops-engineer
-
Sidney, Systems Administrator, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sidney-systems-administrator
-
Sam, Security Analyst, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sam-security-analyst
Further details
There's a complete lack of options for configuring the managed Kubernetes deployed gitlab-runner. The UI expose only two things currently: "Install", and "Upgrade". Unfortunately, this doesn't provide the same experience as for the shared runners because cache is not persisted between runs.
Proposal
Enable configuration of the cache, such that a custom store can be used. Alternatively, ship a localized cache option which will persist between jobs
Permissions and Security
I believe the shared runners are using GCP storage, who's credentials shouldn't be accessible from the managed Kubernetes gitlab-runner. For self-hosted solutions, the configuration is readily available for manipulation. GitLab GCP credentials cannot live in config, but might be accessible from somewhere else - in order to provide the same experience between shared runners, and managed Kubernetes runners?
What does success look like, and how can we measure that?
Cache start working on the managed runners, either through code change - or expose parts of gitlab-runner configuration in the UI