Enabling GitLFSPull in scm object used by checkout(scm) in pipeline

Using Jenkins
1

Hello good CI/CD specialists and users, I’ve got a pretty weird question.
We have both Git LFS enabled and disabled repos, currently most of our LFS-enabled repos using teams are doing their clones/pulls in two steps - one with the default Jenkins’ method of checkout(scm) and then another with ‘sh’, so shell-run, with ‘git lfs pull’ once entered in the repo. We wanted to have the checkout(scm) be incorporating the LFS tracked stuff on pulls/clones on worker nodes and not do it in the complex two steps approach, especially since $class: ‘GitSCM’ (jenkins.io) documentation mentions it is possible to have it enabled in one go.
Our Jenkins slaves/worker nodes all come with git-lfs installed, so that 2-step approach works, but we currently have LFS initialised globally with skip smudge filter. If we initialise it with smudge filter enabled, the checkout(scm) fails, or rather hangs awaiting for credentials for the LFS files, one by one as per LFS behaviour. My guess is that the ‘GitLFSPull’ extension of ‘GitSCM’ wraps the ‘git lfs pull/clone’ credentials calls into the same default checkout’s and provides them as needed.
I know there is the option to specify extension classes when doing checkout with the set of params by adding ‘[$class: ‘GitLFSPull’]’ in ‘[$class: ‘GitSCM’]’ that ultimately get converted to scm object in the background, but how do I add it within Jenkins pipeline to the scm object that checkout(scm) uses so that it incorporates the Git LFS class? Basically, how do I extend the existing/default scm object with the LFS extension?
I tried with scm.extensions.add([$class: ‘GitLFSPull’]) but it cannot work, cause extensions field in scm object is a describablelist of gscmextensions and gscmextensiondescription objects and the added object is treated as a map/list and it does not incorporate the corresponding Jenkins extension object/class, so the addition fails.
Therefore, my question is how do I (re)build the scm object of Jenkins pipeline from within the pipeline to include LFS step as offered by that Jenkins extension in checkout method call? Or how do I decompose the scm object into its parameters list to add the class there and then rebuild back into scm object for further use. Maybe I could get the target directory out of the scm object to do a quick programmed second step ‘git lfs pull’ in a wrapper method that calls executor.checkout(scm) so something like executor.sh(’ cd ${scm.targetpath} && git lfs pull ; cd - ') albeit I’d still need to get the scm object’s or checkout method’s credentials for such extra step…
And a sub question - can I use the extension on Git LFS-disabled repos, or would it then fail due to no LFS-tracked files in repo (I’m asking cause not all of our repos have LFS in use, actually we have less LFS-using ones than not, and don’t want to end up breaking checkouts of those)?

2

Here are some examples that I think may address your specific need. They do not all illustrate how to add GitLFSPull but they illustrate adding other extensions to the existing extensions provided with the multibranch scm.extensions:

3

I tried to use this option by going through with basically:

if (scm.getClass().toString().contains(‘GitSCM’)) {
debugOn = executor.env().DEBUG.toBoolean()
executor.checkout([$class: ‘GitSCM’,
branches: scm.branches,
gitTool: scm.gitTool,
browser: scm.browser,
extensions: scm.extensions + [[$class: ‘GitLFSPull’], [$class: ‘GitSCMChecksExtension’, verboseConsoleLog: debugOn],],
doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
submoduleCfg: scm.submoduleCfg,
userRemoteConfigs: scm.userRemoteConfigs
])
}

so generally, I attempted to use everything as set in the scm object whilst adding the GitLFSPull extension and hopefully making it more verbose through GitSCMChecksExtension extension as per your linked suggestions how to do it… This however has not resulted in any checkout being made (no files checked out/pulled from repo).
I then tried with single extensions addition as in:

extensions: scm.extensions + [[$class: ‘GitLFSPull’]],

as well as:

extensions: scm.extensions + [$class: ‘GitLFSPull’],

or even no extensions alteration, just copy-over:

extensions: scm.extensions,

but neither got me through with the checkout - last entries related to checkout stage in jenkins run logs show:

git --version # ‘git version 1.8.3.1’
using GIT_ASKPASS to set credentials Generic user for accessing (…)
git fetch --no-tags --progress (…)

And just to explain - if I set GitLFSPull-enabling option in Jenkins project definition in Jenkins UI and use the basic checkout() method, everything is pulled correctly, as what follows is typically a set of:

git config remote.origin.url (…)
git config --add remote.origin.fetch (…)
git checkout -f (…)
git rev-list --no-walk (…)

steps which due to actual checkout call yield repo files being downloaded.
However, that also means the whole repo is being pulled on controller node as well, which quickly eats up space there, whilst we need full LFS pulls when Dev teams require it, not just when repos have LFS enabled. So, it might not be practical to have the Jenkins UI configuration redone everywhere, plus, in our environment, we have multitudes of projects and repos definitions and doing such manual change from the administrative UI of Jenkins instance per project/repo is kind of out of the question, that’s why we need to expose LFS feature in Jenkins pipeline by adding/enabling GitLFSPull extension when needed.