Problem
actions/checkout currently provides an lfs boolean, but no way to limit which Git LFS objects are downloaded.
This is expensive for repositories that contain several independent sets of large LFS assets while a workflow needs only some of them. Enabling lfs: true downloads all applicable LFS objects, including assets irrelevant to the job.
In a representative CI workflow, adding several hundred MiB of unrelated LFS objects increased checkout time by roughly 30–40 seconds. Selectively excluding those objects restored the previous overall checkout time.
Related: #1839
Current workaround
Selective fetching currently requires bypassing the action's LFS handling and reproducing it in separate steps:
- uses: actions/checkout@v7
env:
GIT_LFS_SKIP_SMUDGE: "1"
with:
fetch-depth: 0
- name: Fetch required Git LFS objects
run: |
git lfs install --local
git lfs pull --exclude="path/to/unused-assets/**,another/unused/path/**"
This works, but every consumer must understand and maintain the interaction between checkout, LFS smudging, LFS installation, and the selective pull.
Proposed interface
Add optional lfs-include and lfs-exclude inputs:
- uses: actions/checkout@v7
with:
lfs: true
lfs-include: |
path/to/required-assets/**
lfs-exclude: |
path/to/unused-assets/**
another/unused/path/**
Supporting both inputs would mirror Git LFS's existing include/exclude filtering and cover both allow-list and deny-list use cases.
Expected behavior
- When
lfs: true is set, lfs-include and lfs-exclude constrain the LFS objects fetched and checked out.
- Multiline input is converted into the comma-separated patterns expected by Git LFS.
- An omitted or empty filter preserves the existing behavior.
- Existing workflows using only
lfs: true remain fully backward compatible.
- If either filter is provided while
lfs is not enabled, the action should report a clear configuration error.
The implementation could configure the repository-local lfs.fetchinclude and lfs.fetchexclude values, or pass equivalent filters to the relevant Git LFS commands.
Problem
actions/checkoutcurrently provides anlfsboolean, but no way to limit which Git LFS objects are downloaded.This is expensive for repositories that contain several independent sets of large LFS assets while a workflow needs only some of them. Enabling
lfs: truedownloads all applicable LFS objects, including assets irrelevant to the job.In a representative CI workflow, adding several hundred MiB of unrelated LFS objects increased checkout time by roughly 30–40 seconds. Selectively excluding those objects restored the previous overall checkout time.
Related: #1839
Current workaround
Selective fetching currently requires bypassing the action's LFS handling and reproducing it in separate steps:
This works, but every consumer must understand and maintain the interaction between checkout, LFS smudging, LFS installation, and the selective pull.
Proposed interface
Add optional
lfs-includeandlfs-excludeinputs:Supporting both inputs would mirror Git LFS's existing include/exclude filtering and cover both allow-list and deny-list use cases.
Expected behavior
lfs: trueis set,lfs-includeandlfs-excludeconstrain the LFS objects fetched and checked out.lfs: trueremain fully backward compatible.lfsis not enabled, the action should report a clear configuration error.The implementation could configure the repository-local
lfs.fetchincludeandlfs.fetchexcludevalues, or pass equivalent filters to the relevant Git LFS commands.