Git LFS pointers committed to main branch after GitHub Actions checkout lacked LFS pull: large files missing in CI and deployed artifact

Environment

Monorepo on GitHub using Git LFS for large model assets; CI pipeline runs on GitHub Actions with actions/checkout@v2, build steps that expect real files under 'assets/models'; artifacts deployed to staging via GitHub Pages; repository is public but LFS files tracked and stored in GitHub LFS.

Symptoms

Staging deploys from CI started failing: runtime errors 'cannot open model file' and files under assets/models appear as small text pointer files containing 'version https://git-lfs.github.com/spec/v1' rather than expected binaries; local clones (developer machines) have correct binary files.

Observations

CI job log shows actions/checkout@v2 running with default settings; no 'git lfs pull' step present; previous successful builds used a self-hosted runner that had a global Git LFS cache configured; actions/checkout v2 does not fetch LFS by default unless 'lfs: true' specified; the pointer files in the repo are valid LFS pointers and CI's git status shows no changes; adding an explicit 'git lfs pull' step during CI resolves the problem in test runs.

Already attempted

Added 'with: lfs: true' to actions/checkout step and reran pipeline (fixed in one run); tried adding separate 'git lfs install' + 'git lfs pull' steps as alternative (also fixed). Reverting to older checkout action didn't change behavior. Ensured GITHUB_TOKEN has read access to LFS objects (default).

Question

Why did CI start delivering LFS pointer files instead of real assets, and what is the safest CI change to ensure LFS objects are fetched reliably during GitHub Actions builds without leaking or storing large binaries in the repo history?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 2d ago• Trouble ID

Most likely causes

actions/checkout running with default options that don't pull LFS objects on GitHub-hosted runners 100%

Switch from self-hosted runner (with cached LFS) to GitHub-hosted runner that lacks LFS fetch configuration 90%

LFS objects access issue (token permissions), though default GITHUB_TOKEN normally suffices for public repos 5%

Summary

By default actions/checkout@v2 will fetch LFS objects only if configured (lfs: true) or if the runner environment has a cached LFS store. Changes in runner type or action updates can cause LFS objects to be omitted, leaving pointer files in the working tree. The correct, reversible fix is to ensure the checkout action fetches LFS or to run 'git lfs pull' during the job. Avoid committing large binaries directly to Git history; use LFS as intended.

Suggested Fixes

Diagnostic step 1

Add 'with: lfs: true' to actions/checkout@v2 step in workflow to fetch LFS objects automatically (reversible change to CI config).

Diagnostic step 2

Alternatively, add explicit steps: 'git lfs install --local' and 'git lfs pull' after checkout to ensure LFS objects are present; this is explicit and portable across runners.

Diagnostic step 3

Confirm LFS access: for private LFS objects, verify GITHUB_TOKEN permissions or configure a deploy key with LFS read access and use it securely in CI (do not print or store private keys in logs).