Page MenuHomePhabricator
Create Task
Maniphest T11195

Drydock's working copy should run "git lfs fetch && git lfs checkout" for repositories known to use Git LFS
Open, Needs TriagePublic
Actions

Description

We started using Git LFS in a repository and didn't realise that Git LFS checkout / fetch wasn't something that happened automatically as part of git checkout So our binary assets didn't get converted from the Git LFS pointers to the real files, and when we built and packaged a release, we found that the assets were invalid (because they contained the pointer info instead of the actual file).

For now we can workaround the issue by adding git lfs fetch && git lfs checkout to our Harbormaster build plan after the working copy is obtained, but it'd be far better to have Drydock doing this so we're not running these commands for repositories that don't use Git LFS.

Related Objects
Search...

Event Timeline

hach-que created this task.Jun 22 2016, 3:05 AM
epriestley added a parent task: T7789: Support Git Large File Storage.Jun 22 2016, 5:23 PM
epriestley added a subscriber: epriestley.

Offhand, I'm surprised by this. I expect LFS smudging to be a side effect of git checkout and for all Drydock working copy construction pathways to invoke git checkout. This appears consistent with advice from the LFS upstream (albeit a year or so old):

https://github.com/github/git-lfs/issues/325#issuecomment-104673499

However, I haven't actually run this flow myself.

joshuaspence updated the task description. (Show Details)Jun 25 2016, 10:54 AM
joshuaspence updated the task description. (Show Details)
joshuaspence added a subscriber: joshuaspence.
joshuaspence added a project: Drydock.Jun 25 2016, 10:56 AM
epriestley mentioned this in T13032: Upgrading: Git LFS.Dec 18 2017, 5:36 PM
epriestley moved this task from Backlog to Far Future on the Drydock board.Feb 12 2018, 10:58 PM
aeiser added a subscriber: aeiser.Jun 20 2018, 2:37 AM

We have a similar issue - however I think the "fix" is probably worse then the workaround.

In our case we have not run the git lfs install command on our builders - so the .gitconfig is missing the smudge commands.

When a new drydock resource is created, the LFS files are not present until a git lfs fetch and git lfs checkout are run exactly like described in the bug report.

If git lfs install was run prior to initial clone, the performance of that operation would be very slow since GIT_LFS_SKIP_SMUDGE=1 is not configured... and even if it was you would still need to perform an initial lfs fetch afterwards.

hach-que added a comment.Jun 20 2018, 6:31 AM

Back when this was originally reported, I'm pretty sure git lfs clone didn't exist (or at least I wasn't aware of it's existence). The appropriate fix now is probably different to the fix suggested in the original report.

Phabricator · Built by Phacility