• Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Minor Minor
    • git-plugin
    • None

      Issue

      Impacts: Windows and MacOS agents

      After `checkout scmGit(...)`, the local git config has its core.hooksPath set to a null value.

      • Windows: `nul:`
      • Mac: `/dev/null`

       

      Context

      When updating our jenkins instance, we encountered push operations failing on missing LFS objects. This is because `checkout scmGit()` sets the `core.hooksPath` to a null value. Any downstream git operations will fail. Any jobs that execute on the updated agent will be impacted.

      Because the hooksPath is set to null, post-commit scripts are not executed. This prevents LFS objects from being pushed to the LFS server after a commit command is made.

       

      I'd expect that the local git config file would not be altered in any way when using `checkout scmGit()`. This was not occurring on our previous version of jenkins.

       

      Example Error:
      ```

      git push --set-upstream origin testing/lfs-object-test-branch

      remote: error: GH008: Your push referenced at least 2 unknown Git LFS objects:

      remote: 51656cb5f28a18516c818680274d77a4def5af5a8e6523571b0c4f263b935cc9

      remote: 5e22164b0fcab5cbf5a2da096503ef5967b6a973ac5e7badd296dd23792812e9 

      remote: Try to push them with 'git lfs push --all'. {{ }}
      ```

       

      Snippet

      ```

      bat "git config --list --show-origin" 

      // core.hooksPaths is not defined

      def scmVars = checkout scmGit(  branches: [[name: "refs/heads/testing/lfs-object-test-branch"]],
                                      extensions: [
                                          submodule(parentCredentials: true, recursiveSubmodules: true, reference: '', trackingSubmodules: true),
                                          pruneTags(true),
                                          pruneStaleBranch(),
                                          cleanBeforeCheckout(deleteUntrackedNestedRepositories: true),
                                          [$class: 'GitSCMStatusChecksExtension', skip: true, skipProgressUpdates: true],
                                          lfs()],
                                      userRemoteConfigs: [[url: repo, credentialsId: '

      {YOUR_GIT_CREDENTIALS_ID}

      ']])
      bat "git config --list --show-origin"

      // crore.hooksPaths is set to `nul:` or `/dev/null` depending on platform.
      ```

          [JENKINS-73800] GitSCM sets core.hooksPath to null

          Pinned comments

          Pinned by Julius

          Markus Winter added a comment -

          git hooks are explicitly disabled as they might be a security risk.

          Under Manage Jenkins -> Security you can enable hooks on the controller and/or agents.

          Markus Winter added a comment - git hooks are explicitly disabled as they might be a security risk. Under Manage Jenkins -> Security you can enable hooks on the controller and/or agents.

          All comments

          Julius added a comment -

          My current workaround is to call unset on the local git config after every usage of `checkout scmGit()`. Touches a every pipeline file we've written as we rely on the default hooks installed by git and git-lfs.

           

          Note: Only use this if your jenkins environment does not have dependencies on modifing hooks.

          ```

          git config --local --unset core.hooksPath

          ```

          Julius added a comment - My current workaround is to call unset on the local git config after every usage of `checkout scmGit()`. Touches a every pipeline file we've written as we rely on the default hooks installed by git and git-lfs.   Note: Only use this if your jenkins environment does not have dependencies on modifing hooks. ``` git config --local --unset core.hooksPath ```

          Pinned by Julius

          Markus Winter added a comment -

          git hooks are explicitly disabled as they might be a security risk.

          Under Manage Jenkins -> Security you can enable hooks on the controller and/or agents.

          Markus Winter added a comment - git hooks are explicitly disabled as they might be a security risk. Under Manage Jenkins -> Security you can enable hooks on the controller and/or agents.

          Mark Waite added a comment -

          vizionz does the git plugin documentation on security configuration of hooks need improvements to make it more clear?

          Based on the kernel version that you reported, you're running Amazon Linux 2. The Jenkins project stopped supporting Amazon Linux 2 in November 2023 as announced in the blog post and as noted by the Jenkins admin monitor in your installation.

          The git client plugin and git plugin are no longer tested on Amazon Linux 2. As a plugin maintainer, I won't detect issues on Amazon Linux 2 because it is not included in my test configurations.

          When I installed a container image of Amazon Linux 2, it installed command line git 2.40. That version should be new enough that hooks are not needed to support git LFS. However, I'm not 100% certain of that because I don't test Amazon Linux 2.

          Is it OK to close this issue as resolved, "won't fix" or is there more action that you're hoping to see?

          Mark Waite added a comment - vizionz does the git plugin documentation on security configuration of hooks need improvements to make it more clear? Based on the kernel version that you reported, you're running Amazon Linux 2. The Jenkins project stopped supporting Amazon Linux 2 in November 2023 as announced in the blog post and as noted by the Jenkins admin monitor in your installation. The git client plugin and git plugin are no longer tested on Amazon Linux 2. As a plugin maintainer, I won't detect issues on Amazon Linux 2 because it is not included in my test configurations. When I installed a container image of Amazon Linux 2, it installed command line git 2.40. That version should be new enough that hooks are not needed to support git LFS. However, I'm not 100% certain of that because I don't test Amazon Linux 2. Is it OK to close this issue as resolved, "won't fix" or is there more action that you're hoping to see?

          Julius added a comment -

          Thank you for pointing me in the right direction mawinter69! Definitely need to to consider the security concerns when enabling hooks on the agent.

           

          We can close this ticket out!

          Julius added a comment - Thank you for pointing me in the right direction mawinter69 ! Definitely need to to consider the security concerns when enabling hooks on the agent.   We can close this ticket out!

          Julius added a comment - - edited

          markewaite thank you for the highlights here.

          1. The documentation is perfect, it was a fault of mine for not revisiting the documentation page. Something I'll take note to do when we do such a big jump between Jenkins versions. (We won't be doing big jumps like this moving forward.)

          2. We will make it a point to move off Amazon Linux 2 in the near future. Thank you for the call out!

          Let's definitely close this out as won't-fix / not-a-bug.

          Julius added a comment - - edited markewaite thank you for the highlights here. 1. The documentation is perfect, it was a fault of mine for not revisiting the documentation page. Something I'll take note to do when we do such a big jump between Jenkins versions. (We won't be doing big jumps like this moving forward.) 2. We will make it a point to move off Amazon Linux 2 in the near future. Thank you for the call out! Let's definitely close this out as won't-fix / not-a-bug.

            Unassigned Unassigned
            vizionz Julius
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: