Why do I have to pull the lfs separately when using lfs: 'true' #270
Comments
|
I am also wondering this. |
|
Any input on this? Is this the expected behavior? |
|
mybe this is no longer the case, at least on ubuntu[1]. 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 |
|
Just popping in here since someone mentioned this on the Git LFS issue tracker, but are you sure the file you're seeing problems with is properly listed in Also, do you have a public repo that demonstrates this problem? That would be helpful to help whomever is looking at this troubleshoot the problem. |
|
https://github.com/alloverse/alloplace Here's a repo with a github actions that tries to build a docker image. the submodule EDIT: Figured it out. The original checkout wasn't recursive, so that's why lfs pull didn't do anything. And, compounding the confusion: |
|
Came across this issue today as well. The |
|
@itssimon Your lack of way to reproduce or a link to workflow where the issue can be seen only adds confusion and should definitely be considered a bug that needs to be fixed.
Also, So if you're trying to claim that it doesn't works in some case, provide the evidence. |
|
Unfortunately I can't share the private repository, but below are the (truncated) log outputs of our workflow. Once it fails due to LFS files not being downloaded and once it succeeds. SUCEEDING: FAILING: The second run of this workflow eventually fails because LFS files have not been downloaded. Unfortunatley this is not easily reproducible as it happens intermittently. Here's an excerpt from my workflow YAML: name: Tests
on:
push:
branches:
- main
paths-ignore:
- '**/README.md'
pull_request:
branches:
- main
jobs:
check:
runs-on: [self-hosted]
steps:
- uses: actions/checkout@v2
- name: Run static checks
run: make check
- name: Run static checks on demo app
run: |
cd demo && npm ci && cd ..
make check-demo
build:
runs-on: [self-hosted]
strategy:
matrix:
component: [api, celery, demo, inference, prodigy, jobs]
steps:
- uses: actions/checkout@v2
with:
lfs: true
- name: Build Docker image
run: make build-${{ matrix.component }} TAG=$GITHUB_SHAThe first job (check) runs checkout without LFS intentionally and the second job (build) does need the LFS files downloaded and has Is it possible that if by chance these two jobs end up being run on the same worker, the second invocation of the checkout action reuses the repo pulled for the previous job and if that was without LFS files downloaded then the |
|
The way it is showing up for us is:
Adding an extra step to workflow_A after - name: Check out LFS objects
run: git lfs checkout the/files/we/need/ That's basically the same as the comment above, but with confirmation that if the LFS-using workflow goes first, LFS works. |
|
Sounds like that mixing I'd personally suggest using consistent lfs setting across all repo builds. |
|
Using |
|
I agree, the fact that I have to use |
|
Ran into this same issue with the following steps: I fixed it by adding a final |
|
Can anyone trip on this w/o using a self-hosted runner? What's confusing me is that in theory @ifiddynine, here's a thing that should work for your problem: You could even do it for just the one step before you run the |
|
I can confirm that this issue is indeed specific to self hosted runners. |
No, you can't. #270 (comment) provides a repro that doesn't involve self-hosted runner. |
* add version * Ensure that we can do a checkout * indentation * Ensure we are in the right directory * Update idefix-ci.yml * Checkout submodules * add git lfs during checkout * more lfs * Manually add git lfs pull actions/checkout#270 * full blown test suite * update dependencies * remove whitespace, add fork prevention * fix lint * change run names * remove run name
|
@gary-cowell We had to do this as well, but when the |
**User-Facing Changes** N/A **Description** Everytime that some dependabot PR was oppened the following error was preventing the dependabot step to run: `Error when performing the request to https://registry.npmjs.org/yarn/latest; for troubleshooting help, see https://github.com/nodejs/corepack#troubleshooting 3414 at fetch (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:22762:11)` We changed the dependabot-fix script to avoid problems when trying to run corepack enable command. Main changes: - Changing the script order to avoid error when running corepack enable command - Adding 'lfs:true' and removing the manual command 'git lfs pull --include .yarn/' **Relevant links** - https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file - https://github.com/foxglove/studio/actions/runs/8118725898/job/22193503028 - actions/checkout#270 **Checklist** - [x] The web version was tested and it is running ok - [x] The desktop version was tested and it is running ok - [x] I've updated/created the storybook file(s) - [x] The release version was updated on package.json files
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.zipI.e. that's a reference only.
After the extra pull, I see:
-rw-r--r-- 1 runner docker 28956993 Jun 2 07:08 largefile.zipThe 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/mybranchThat 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/mybranchWhich 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.
The text was updated successfully, but these errors were encountered: