Skip to content
LatchkeyLatchkey home

Git LFS objects re-downloaded every run (no cache) in CI

Every CI job that checks out with LFS re-downloads the objects unless .git/lfs is cached. This is slow and burns the monthly bandwidth allowance, and can lead to quota 429s on busy repos.

What this error means

CI logs show the same LFS objects downloading on every run, jobs are slow at checkout, and LFS bandwidth usage climbs quickly.

git-lfs
Downloading assets/model.bin (512 MB)
Downloading assets/data.parquet (240 MB)
# identical downloads repeat on every run, no cache hit

Common causes

No cache for the LFS object store

The .git/lfs directory is not cached, so each run starts with an empty object store and re-fetches everything.

A cache key that never hits

A key based on volatile values (like the commit SHA alone) changes every run, so the cache never restores.

How to fix it

Cache .git/lfs with a stable key

  1. Add an actions/cache step keyed on the set of LFS objects.
  2. Restore it before checkout so objects are reused.
  3. Fall back to a prefix restore-key for partial hits.
.github/workflows/ci.yml
- uses: actions/cache@v4
  with:
    path: .git/lfs
    key: lfs-${{ hashFiles('.lfs-assets-id') }}
    restore-keys: lfs-
- uses: actions/checkout@v4
  with:
    lfs: true

Fetch only needed objects

Pair caching with include/exclude filters so jobs pull a smaller, cacheable subset.

Terminal
git lfs pull --include="assets/dist/*"

Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

.github/workflows/ci.yml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached

How to prevent it

  • Cache .git/lfs with a key tied to the object set.
  • Use restore-keys for partial cache hits.
  • Fetch only the objects each job needs.

Frequently asked questions

What causes Git LFS objects re-downloaded every run (no cache) in CI?
There are 2 common causes: no cache for the lfs object store and a cache key that never hits. The .git/lfs directory is not cached, so each run starts with an empty object store and re-fetches everything.
How do I fix Git LFS objects re-downloaded every run (no cache) in CI?
There are 2 fixes depending on which cause you have: cache .git/lfs with a stable key and fetch only needed objects. Work through them in order, since the first is the most common.
What does Git LFS objects re-downloaded every run (no cache) in CI actually mean?
CI logs show the same LFS objects downloading on every run, jobs are slow at checkout, and LFS bandwidth usage climbs quickly.
How do I stop Git LFS objects re-downloaded every run (no cache) in CI happening again?
Cache .git/lfs with a key tied to the object set. The prevention section lists 3 changes that keep it from recurring.

Related guides

References

Not every red build is your code. Latchkey repairs the ones that are not, on the runner. Start free → 30-day trial · No credit card