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

Add an actions/cache step keyed on the set of LFS objects.
Restore it before checkout so objects are reused.
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/*"

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.