What's the expiry for cache for Gitlab CI runners

Caching on Gitlab Runner CI

The GitLab CI runners can save artifacts and use it throughout the pipeline. This can help in speeding up the build time. By default, artifacts have an expiry time of 30 days unless specified otherwise.

We wanted to explore caching and uploading to a cloud bucket like Google Cloud Storage. I was wondering what would be the expiry time of that cache on that cloud bucket. Is it determined by the runner or the cloud storage bucket? Does the cache live on forever?

The question is for a self-managed GitLab. I was wondering if anyone has experienced this question before.

@asadmansr thanks for the question and welcome to the forum! :tada:

There are a couple of details here:

First, as you may know, you can use any GCS bucket for the runner’s cache by configuring it as specified here.

Secondly, the default expiration for artifacts can be set by the instance administrator, and is by default 30 days. Of course, this can be overridden by specifying expire_in in their .gitlab-ci.yml.

I would note that also, you can use native GCS object expiration in addition to this, so I would recommend both. That way, you have ultimate control over the artifacts at the bucket level (in addition to GitLab’s expiration settings). Exactly how to set that up would depend on your use case.

For those who are after the answer for the SaaS Gitlab shared runner pool: 14 days.

These runners share a distributed cache through use of a Google Cloud Storage (GCS) bucket. Cache contents not updated within the last 14 days are automatically removed through use of an object lifecycle management policy.

Source: SaaS runners on Linux | GitLab