CI Cache key hash never updated when using pattern in cache:key:files since updating to GitLab 18.4.0

Summary

Since we migrated our GitLab Premium Self-Hosted to the version 18.4.0, we encounter a problem with our cache on GitLab CI/CD ; before migration, when using files as cache key, with a wildcard pattern, we had a hash in the cache key, which changed when our files were modified. Since migration, this doesn't work anymore ; all our jobs share the same default hash, regardless of any change, which breaks some of our workflows, which relies heavily on this mechanic. I reproduced the problem on gitlab.com as well.

Steps to reproduce

In my tests, I reproduced this bug with any wildcard pattern in cache:key:files.

Example Project

For example, I created a project which illustrates the problem. The CI only computes a concatenation of all markdown files in source, but we see in the pipelines that cache key never changes, and the last jobs keeps the old content, even if a subsequent commit changes it.

What is the current bug behavior?

We always have default as hash in cache key.

What is the expected correct behavior?

We should have a dynamic hash, computed from files paths and hashes from latest commits changing these files.

Relevant logs and/or screenshots

Log

Running with gitlab-runner 18.4.0~pre.115.gb2218bab (b2218bab)
  on blue-6.saas-linux-small-amd64.runners-manager.gitlab.com/default nN8vMRS9Z, system ID: s_a899fcd611a3
Preparing the "docker+machine" executor
00:06
Using Docker executor with image alpine:latest ...
Using effective pull policy of [always] for container alpine:latest
Pulling docker image alpine:latest ...
Using docker image sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 for alpine:latest with digest alpine@sha256:4bcff63911fcb4448bd4fdacec207030997caf25e9bea4045fa6c8c44de311d1 ...
Preparing environment
00:00
Using effective pull policy of [always] for container sha256:eab223288bcdad37535303858f50c965374213b4eaa107642e5abdad55662d4a
Running on runner-nn8vmrs9z-project-74634840-concurrent-0 via runner-nn8vmrs9z-s-l-s-amd64-1758550121-2f77f9ce...
Getting source from Git repository
00:02
Gitaly correlation ID: ead562ac372a41c58c5177e81a8999e6
Fetching changes with git depth set to 20...
Initialized empty Git repository in /builds/yanbuatois/cache-key-hash/.git/
Created fresh repository.
Checking out 13d902d6 as detached HEAD (ref is main)...
Skipping Git submodules setup
$ git remote set-url origin "${CI_REPOSITORY_URL}" || echo 'Not a git repository; skipping'
Restoring cache
00:00
Checking cache for 0_source/*-default-protected...
Downloading cache from https://storage.googleapis.com/gitlab-com-runners-cache/project/74634840/0_source/%2A-default-protected  ETag="dcdbc2a1edfdb0739167add005948d5d"
Successfully extracted cache
Executing "step_script" stage of the job script
00:01
Using effective pull policy of [always] for container alpine:latest
Using docker image sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 for alpine:latest with digest alpine@sha256:4bcff63911fcb4448bd4fdacec207030997caf25e9bea4045fa6c8c44de311d1 ...
$ if [ ! -f output.md ]; then
Saving cache for successful job
00:01
Creating cache 0_source/*-default-protected...
output.md: found 1 matching artifact files and directories 
Archive is up to date!                             
Created cache
Cleaning up project directory and file based variables
00:00
Job succeeded

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

We use GitLab 18.4.0 with kubernetes. The problem was occurring before bumping our gitlab-runners to 18.4.0 (we had gitlab-runners in 18.3.1) and after.

Results of GitLab application Check

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.