GitLFSPull Jenkins SCM插件无法解析LFS指针，求正确用法

First, let's start with the most obvious issue in your provided Groovy code—a syntax error that might be breaking the GitLFSPull extension loading:

Looking at your extensions list:

[$class: 'GitLFSPull']
[$class: 'UserIdentity', email: 'xyz@gmail.com', name: 'xyzzy'],

You're missing a trailing comma after the GitLFSPull entry. In Groovy, this parsing error could mean the plugin isn't actually initializing properly, even though the log says "Enabling Git LFS pull". Fix that comma first:

[$class: 'GitLFSPull'], // Add this comma
[$class: 'UserIdentity', email: 'xyz@gmail.com', name: 'xyzzy'],

Next, let's walk through other common pitfalls and fixes:

• Ensure Git LFS is installed on your Jenkins agent
  The git lfs pull command will fail silently (or with non-obvious log entries) if the Git LFS client isn't installed on the agent running your Pipeline. Verify this by adding a quick test step right after checkout:

  sh 'git lfs version'
  

  If it's missing, install Git LFS on your agent (via package manager like apt-get install git-lfs on Ubuntu, or brew install git-lfs on macOS), or add a setup step directly in your Pipeline:

  sh 'git lfs install --skip-repo'
  

• Fix your branch reference configuration
  Looking at your logs, there's a suspicious line:

  git rev-parse refs/remotes/origin/origin/feature/xyz^{commit} # timeout=10
  This double origin/origin suggests your branch name setup is off. In the GitSCM branches parameter, you shouldn't prefix the branch name with origin/—your userRemoteConfigs already defines origin as the remote. Change this:

  branches: [[name: "origin/" + params.SOURCE_BRANCH]]
  

  To:

  branches: [[name: params.SOURCE_BRANCH]]
  

  This ensures Jenkins checks out the correct remote branch without duplicate origin references, which might be confusing the LFS pull logic.

• Verify credentials have access to LFS objects
  Even if your SSH credentials work for Git, some setups separate permissions for LFS storage. Test manually on the agent: clone the repo with the same credentials, run git lfs pull origin, and check if you get the actual files. If this fails, debug credential access for LFS (most cases use the same Git credentials, but it's worth ruling out).

• Check plugin version and enable verbose logs
  Older versions of the GitLFSPull plugin had bugs around post-checkout execution. Upgrade to the latest version via Jenkins Plugin Manager. Also, temporarily enable "Debug" level logs for your Pipeline to uncover hidden errors in the git lfs pull step that aren't showing up in your current logs.

• Fallback to manual git lfs pull if needed
  If the plugin still doesn't behave as expected, bypass it and run the command directly after checkout as a reliable fallback:

  checkout changelog: true, poll: true, scm: [/* your existing SCM config without GitLFSPull */]
  sh 'git lfs pull origin'
  

  This ensures LFS objects are pulled explicitly, and you can see the full command output to debug any issues.

内容的提问来源于stack exchange，提问作者Sandeep Anand