Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-56569

Prevent automatic pulling of lfs files if no GitLFSPull option is set

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-client-plugin
    • Labels:
      None
    • Environment:
      git-client-plugin 2.7.6
    • Similar Issues:

      Description

      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

      1. If the remote server requires authentication and none is configured on the system on a Jenkins agent (e.g. ssh key in ~/.ssh/), the checkout fails.
      2. 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.

        Attachments

          Issue Links

            Activity

            Hide
            renescheibe René Scheibe added a comment -

            Right, that's a breaking change so to speak.

            If GIT_LFS_SKIP_SMUDGE=1 is always set to disable any enabled smudge filter and git lfs pull is only performed when the "Git LFS pull after checkout" behaviour is specified, users that currently have the smudge filter enabled via a system/global/local git config would have to change their job configuration.

            Show
            renescheibe René Scheibe added a comment - Right, that's a breaking change so to speak. If GIT_LFS_SKIP_SMUDGE=1 is always set to disable any enabled smudge filter and git lfs pull is only performed when the "Git LFS pull after checkout" behaviour is specified, users that currently have the smudge filter enabled via a system/global/local git config would have to change their job configuration.
            Hide
            renescheibe René Scheibe added a comment -

            Above I also linked JENKINS-45228 which is about git LFS at merge time. (This here is about git LFS at checkout time).

            Show
            renescheibe René Scheibe added a comment - Above I also linked JENKINS-45228 which is about git LFS at merge time. (This here is about git LFS at checkout time).
            Hide
            renescheibe René Scheibe added a comment -

            Above I also linked JENKINS-59516 which is about git LFS pull for submodules. In case it's decided here that the smudge filter is always disabled via GIT_LFS_SKIP_SMUDGE=1, then the referenced issue has to be worked on too. Otherwise it would not be possible at all to pull LFS files in submodules (even not with configuration outside of Jenkins).

            Show
            renescheibe René Scheibe added a comment - Above I also linked JENKINS-59516 which is about git LFS pull for submodules. In case it's decided here that the smudge filter is always disabled via GIT_LFS_SKIP_SMUDGE=1 , then the referenced issue has to be worked on too. Otherwise it would not be possible at all to pull LFS files in submodules (even not with configuration outside of Jenkins).
            Hide
            angelfighter Helene W added a comment -

            huhu

            would be cool if this request is implemented (soon).

            In my company we have the use case that we need just some information from a repository but not its large files. Right now there is no possibility to clone a repository without large files. Either it's cloned with large files or you checkout with the option "Git LFS pull after checkout" which actually just postpones the pull to after the checkout.

             

            Please, please, please, implement a possibility to checkout/clone completely without lfs.

            Thank you 

             

            Show
            angelfighter Helene W added a comment - huhu would be cool if this request is implemented (soon). In my company we have the use case that we need just some information from a repository but not its large files. Right now there is no possibility to clone a repository without large files. Either it's cloned with large files or you checkout with the option "Git LFS pull after checkout" which actually just postpones the pull to after the checkout.   Please, please, please, implement a possibility to checkout/clone completely without lfs. Thank you   
            Hide
            markewaite Mark Waite added a comment -

            I'm not likely to implement a switch that will disable LFS completely.

            Next large project for the git plugin is to create withGitHTTPCredentials and withGitSSHCredentials pipeline tasks that will provide the necessary files and environment so that the user can perform exactly the authenticated git commands they want from sh, bat, and powershell steps.

            The idea is that instead of many different switches that are always trying to find the right mix of simplicity and power, the user would perform a checkout with a command like this:

                withGitHTTPCredentials(credentialid: 'my-personal-access-token-for-my-provider') {
                    sh 'git clone --single-branch https://github.com/MarkEWaite/my-private-repo'
                }
            

            The previous syntax with checkout scm would continue to work and be fully supported, but this will allow submodule use cases, LFS use cases, single branch use cases, and more.

            Show
            markewaite Mark Waite added a comment - I'm not likely to implement a switch that will disable LFS completely. Next large project for the git plugin is to create withGitHTTPCredentials and withGitSSHCredentials pipeline tasks that will provide the necessary files and environment so that the user can perform exactly the authenticated git commands they want from sh , bat , and powershell steps. The idea is that instead of many different switches that are always trying to find the right mix of simplicity and power, the user would perform a checkout with a command like this: withGitHTTPCredentials(credentialid: 'my-personal-access-token-for-my-provider') { sh 'git clone --single-branch https://github.com/MarkEWaite/my-private-repo' } The previous syntax with checkout scm would continue to work and be fully supported, but this will allow submodule use cases, LFS use cases, single branch use cases, and more.

              People

              • Assignee:
                Unassigned
                Reporter:
                renescheibe René Scheibe
              • Votes:
                1 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated: