Skip to content

Resolve "Backend: Runner cache prefix causes incorrect cache to be used"

What does this MR do and why?

Currently the runner cache prefix causes the incorrect cache to be used:

  • Job 1 creates a cache using two key:files keywords. key:files:lockfile1.json and key:files:lockfile2.json
  • This creates 0-COMMITSHA and 1-COMMITSHA
  • Job 2 also creates a cache using two key:files keywords. key:files:lockfile2.json and key:files:lockfile3.json
  • This again creates 0-COMMITSHA and 1-COMMITSHA --- but these are not associated with the correct keys. They are simply based on the order. Even re-ordering lockfile1.json and lockfile2.json will cause this issue

Instead of the above, what we should be expecting is that each job should respect a key:files cache throughout the entire pipeline. For example, key:files:backend/package-lock.json and key:files:frontend/package-lock.json should have a unique cache and prefix and not based on index order when added to the job:

  • Job 1 creates a cache using two key:files keywords. key:files:lockfile1.json and key:files:lockfile2.json
  • This creates 0-COMMITSHA and 1-COMMITSHA
  • Job 2 also creates a cache using two key:files keywords. key:files:lockfile2.json and key:files:lockfile3.json
  • This again creates 1-COMMITSHA and 2-COMMITSHA
  • Job 3 creates a cache using two key:files keywords. key:files:lockfile2.json and key:files:lockfile1.json
  • This again creates 1-COMMITSHA and 0-COMMITSHA

The approach taken to solve this issue is to update the prefix for the cache from just index to index + string of file names

Screenshots or screen recordings

If we were to set up a project such as the one here we would see the following behaviours:

Current naming for cache (for all three jobs): old-1

Cache names after proposed changes: new-1 new-2 new-3

How to set up and validate locally

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #388374 (closed)

Edited by Sam Kim

Merge request reports

Loading