-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
git-client-plugin 2.7.6
Depending on the used method to install git on a system, git lfs is enabled per default on a system via these settings in the system-wide config file:
[filter "lfs"] clean = git-lfs clean -- %f smudge = git-lfs smudge -- %f process = git-lfs filter-process required = true
This means that even if no "git lfs pull" is performed explicitly, on checkout lfs files are pulled automatically due to the smudge filter.
Problems
- If the remote server requires authentication and none is configured
on the systemon a Jenkins agent (e.g. ssh key in ~/.ssh/), the checkout fails. - If lfs files shall not be pulled at all, there is no way to configure this in the plugin.
I therefore suggest to always set the environment variable GIT_LFS_SKIP_SMUDGE=1 even if no "GitLFSPull" option was specified.
This makes sure that no "git lfs" commands that are not controlled by the git-client-plugin are launched and thus resolves the issue that the checkout fails in case the remote server requires authentication.
This also prevents pulling lfs files regardless of a system's configuration and requires to explicitly pull lfs files via the "GitLFSPull" option.
- relates to
-
JENKINS-59139 don't set GIT_LFS_SKIP_SMUDGE=1 anymore while cloning with git 2.15+
-
- Open
-
-
JENKINS-45228 Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command
-
- Closed
-
-
JENKINS-59516 There is no way to pull LFS files for submodules in GIT
-
- Closed
-
Shouldn't then the clone itself fail, too?
Normal ssh clone setups nowadays execute `git-lfs-authenticate` to obtain http urls and authentication, even when purely cloning over ssh. Once you're able to clone, resolving LFS pointers should work too.
Why don't you want your lfs pointers to be resolved while checking out? If that smudge filter is installed system-wide, why should jenkins override that behaviour at all, or silently flip its default?
Again, this really sounds more like a broken LFS backend on your side, than something that should be changed on Jenkins' side.
This would also be problematic with declarative pipelines, for which there's currently no way to enable the GitLFSPull option.