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

Git tool chooser unpacks then deletes git install in each job

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • Jenkins 2.263
      Git plugin 4.4.5
      Git client plugin 3.5.1

      I have multiple git tool installers defined for Windows computers so that jobs have the option to declare their dependency on a specific version of Git for Windows. The git tool chooser iterates over each of those installers, installing them on the Windows computer as a tool, then deletes them.

      That's inefficient and should be resolved either by a code change to retain multiple tool installations or by documenting a technique so that the tool installers will not delete one another when multiple versions are installed.

      Job output in the console log looks like this:

      Started by upstream project "Bugs-Individual/Bugs-10-000-to-19-999/JENKINS-15103-open-pack-file-prevents-wipe-cli-jgit" build number 20
      originally caused by:
       Started by user Mark Waite
      Running as SYSTEM
      [EnvInject] - Loading node environment variables.
      Building remotely on mark-pc3-ssh (git-1.9+ amd64) in workspace C:\J\PC\workspace\Bugs-Individual\Bugs-10-000-to-19-999\JENKINS-15103-open-pack-file-prevents-wipe-cli-jgit\label\mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/MinGit-2.27.0-busybox-64-bit.zip to C:\J\PC\tools\git on mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/PortableGit-2.11.1.zip to C:\J\PC\tools\git on mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/PortableGit-2.17.1.zip to C:\J\PC\tools\git on mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/PortableGit-2.20.1.zip to C:\J\PC\tools\git on mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/PortableGit-2.25.1.zip to C:\J\PC\tools\git on mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/PortableGit-2.26.2.zip to C:\J\PC\tools\git on mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/PortableGit-2.28.0.zip to C:\J\PC\tools\git on mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/PortableGit-2.29.0.zip to C:\J\PC\tools\git on mark-pc3-ssh
      Unpacking https://home.markwaite.net/~mwaite/git/PortableGit-2.29.1.zip to C:\J\PC\tools\git on mark-pc3-ssh
      The recommended git tool is: C:\J\PC\tools\git\PortableGit-2.29.1\bin\git.exe
      No credentials specified
      Wiping out workspace first.
      Cloning the remote Git repository
      Avoid fetching tags
      Honoring refspec on initial clone
      Cloning repository https://github.com/MarkEWaite/jenkins-bugs
      

      Each of the "Unpacking" statements results in the tools\git directory being emptied of the current git tool then it is populated with the git tool that is being iterated. Since each of those git tool zip files is a 100 MB zip file, time is wasted installing each tool and then removing it.

      I now avoid the issue by having only a single git tool definition for the Windows agents. See my docker-lfs jenkins.yaml file for an example.

          [JENKINS-64092] Git tool chooser unpacks then deletes git install in each job

          markewaite A bit of a context about this behaviour: 
          While recommending a git tool, the chooser gets into a tricky situation when the user has chosen `jgit/jgitapache` but the recommendation is `cli-git` on the basis of the heuristics. In this case the GitToolChooser has to provide the git implementation which is installed and compatible with the agent this job would be running on. To do so, we basically get the list of all git tool installations which the user defines and then iterate through each of them to decide if they are installed in the particular running agent.

          My belief is that while inspecting each installation for compatibility with the current running agent, the ToolInstallation class installs the git tool and then validates it. I may be wrong here, I have to dig deeper to understand that. 

          This behaviour is what might be causing this redundancy. But since the Tool Chooser has no pre existing knowledge of the correct installed tool on that particular agent, I did not see a better way to do it at the time.

          Rishabh Budhouliya added a comment - markewaite  A bit of a context about this behaviour:  While recommending a git tool, the chooser gets into a tricky situation when the user has chosen `jgit/jgitapache` but the recommendation is `cli-git` on the basis of the heuristics. In this case the GitToolChooser has to provide the git implementation which is installed and compatible with the agent this job would be running on. To do so, we basically get the list of all git tool installations which the user defines and then iterate through each of them to decide if they are installed in the particular running agent. My belief is that while inspecting each installation for compatibility with the current running agent, the ToolInstallation class installs the git tool and then validates it. I may be wrong here, I have to dig deeper to understand that.  This behaviour is what might be causing this redundancy. But since the Tool Chooser has no pre existing knowledge of the correct installed tool on that particular agent, I did not see a better way to do it at the time.

            Unassigned Unassigned
            markewaite Mark Waite
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: