Cache fallback mechanism does not account for hash-appended keys with cache:key:files

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Actual behavior: When cache:key:files is utilized in GitLab CI/CD, a unique cache key is generated by appending a hash based on file content, such as cache-main-${HASH}. This specificity leads to a situation where caches generated in the default branch are not readily accessible to feature branches using a simple fallback_key like cache-main. The fallback_keys mechanism expects an exact match, thus it cannot reconcile with the dynamically generated hash in the primary cache key, leading to a scenario where caches intended for sharing across branches are not utilized effectively due to the mismatch between the expected fallback_key and the actual hashed cache key.

job:
  cache:
    - key:
        prefix: cache-$CI_COMMIT_REF_SLUG
        files:
          - package-lock.json
      fallback_keys:
        - cache-$CI_DEFAULT_BRANCH
      paths:
        - node_modules/

Expected behavior: We propose allowing fallback_keys to support pattern matching or a more lenient matching strategy. For example, if the main branch generates a cache with cache-main-${HASH}, feature branches could specify a fallback key pattern like cache-main-* to match any hash-appended version of the cache-main key. This approach would mirror GitHub Actions' restore_keys functionality, facilitating better cache reuse across branches and improving CI/CD efficiency.

job:
  cache:
    - key:
        prefix: cache-$CI_COMMIT_REF_SLUG
        files:
          - package-lock.json
      fallback_keys:
        - cache-$CI_DEFAULT_BRANCH-*
      paths:
        - node_modules/

Note: This feature request is made considering that the "Use separated cache for protected branches" setting is disabled, underscoring the need for flexible cache sharing across branches.

References:

Edited by 🤖 GitLab Bot 🤖