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

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

    XMLWordPrintable

    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 (e.g. ssh key), 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

          Activity

          Hide
          flokli Florian Klink added a comment -

          If the remote server requires authentication and none is configured on the system (e.g. ssh key), the checkout fails.

          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.

          If lfs files shall not be pulled at all, there is no way to configure this in the plugin.

          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?

          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.

          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.

           

          Show
          flokli Florian Klink added a comment - If the remote server requires authentication and none is configured on the system (e.g. ssh key), the checkout fails. 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. If lfs files shall not be pulled at all, there is no way to configure this in the plugin. 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? 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. 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.  
          Hide
          flokli Florian Klink added a comment -

          It looks like this is already implemented in https://github.com/jenkinsci/git-client-plugin/commit/853603cccd4434b116ef9b8e094c3f5b815aa75a - however, the git lfs pull doesn't seem to properly replace lfs pointers…

          Show
          flokli Florian Klink added a comment - It looks like this is already implemented in  https://github.com/jenkinsci/git-client-plugin/commit/853603cccd4434b116ef9b8e094c3f5b815aa75a  - however, the git lfs pull doesn't seem to properly replace lfs pointers…

            People

            • Assignee:
              markewaite Mark Waite
              Reporter:
              renescheibe René Scheibe
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: