Closed eleksaggr closed 5 months ago
We don't do anything for lfs in kas so far (except for installing the tool into the container image). That is probably easy to fix in https://github.com/siemens/kas/blob/6dd27e7c62620090f8beb78f46d262cd0fcd04a3/kas/repos.py#L378: Detect, whether the repo uses lfs, then also issue the pull command. Patches welcome - but those has to come from someone familiar with git lfs (I'm not).
Correction: It won't be completely trivial, though, as checkout_cmd only delivers a single command. So more refactoring might be needed.
Still relevant?
@jan-kiszka Not to my workflow, no.
I imagine it might be useful if you were to provide e.g. a binary firmware with your layer. But there is not much stopping you from hosting it somewhere and just fetching it.
The only other use case I have is to store PDF documentation in the layer, but might as well tell the user to just lfs pull it, instead of complicating kas logic.
So can be closed, if nobody else is interested. Thanks
Then let's close until someone else speaks up as well.
I'll chime in here as we have the use case of having recipes that reference a local tar archive of sources to use, and they can't be easily fetched from an external source, so it would be good to host them in LFS instead.
Happy to take patches for that - and to provide guidance for creating them.
I'm not super familiar with git lfs either, but, if you point me where to go in kas I'll see if I can get it working.
I'm not familiar with the git lfs workflow. Just discussed this with @henning-schild, and he thinks the problem may be reducible to basic git configuration in our sandbox so that git clone and checkout would simply do The Right Thing.
Maybe the best thing is to start with a testcase, creating (or picking) some repo that has lfs artifacts and trying to use that as "layer" - we will need that in end anyway. Then explore what steps are needed manually so that we can discuss where they need to be injected in the kas procedures.
Hmm, no follow-ups since then. Guess it's time to close again. If someone still has a need, patches are always welcome.
I have a layer that uses LFS to provide some archives. When I use kas to checkout/build that layer my LFS pointers are not replaced by the actual files. If I only checkout the layer (using kas), navigate to it and then run
git lfs pull
on it, I get the archives and I can proceed as usual. If I usebitbake shell
and try togit lfs pull
in that layer I get:Am I doing something wrong here? Or does kas not work well with LFS?