Why do I have to pull the lfs separately when using lfs: 'true'

                  - name: checkout
                    uses: actions/checkout@v2
                    with:
                        lfs: 'true'
                  - name: checkoutLFS
                    uses: actions/checkout@v2
                  - run: git lfs pull

With only the first of those, the source checkout has LFS which look like this:

-rw-r--r-- 1 runner docker 133 Jun 1 15:54 largefile.zip

I.e. that’s a reference only.

After the extra pull, I see:

-rw-r--r-- 1 runner docker 28956993 Jun 2 07:08 largefile.zip

The lfs: ‘true’ is having some effect on the first checkout because I can see it installing LFS and issuing:

/usr/bin/git lfs fetch origin refs/remotes/origin/mybranch

That does not appear to take enough time to be fetching the actual lfs, then it runs

/usr/bin/git checkout --progress --force -B mybranch refs/remotes/origin/mybranch

Which still leaves us with a reference file.

It’s only when I run the second checkout and force a ‘git lfs pull’ do I get the actual file. I don’t see any errors in the first checkout step.

[itssimon]

Using lfs: true everywhere has the downside of more LFS traffic that you have to pay for though. We only need to download these files for container builds. Other steps, like linting the code base, really don’t need to download big files. I still believe this is best addressed in the action itself, so that it does what it promises consistently.

[yair-mantis]

mybe this is no longer the case, at least on ubuntu[1]. using ssh key as secret. i use an ‘ls’ on one of the files after the checkout to verify

name: CI 
on:
  workflow_dispatch:
jobs:
  build:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v2.3.4
        with:
          lfs: 'true'
          submodules: 'recursive'
          ssh-key: ${{ secrets.git_ssh_key }}

        env:
          GIT_CURL_VERBOSE: '1'
          GIT_TRACE: '1'

[1] #311