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

git-client explicitly setting core.symlinks in .git/config

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-client-plugin
    • Labels:
      None
    • Environment:
      # uname -a
      Linux brassett-02 3.2.0-30-virtual #48-Ubuntu SMP Fri Aug 24 17:12:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

      # cat /etc/issue
      Ubuntu 12.04.2 LTS \n \l
    • Similar Issues:

      Description

      We recently upgraded the git-client and jenkins Git plugins to the latest versions.

      We have several projects that contain symlinks that are checked directly into git.

      When testing using vanilla git on the commandline, the repo is created correctly either using 'git clone' or 'git init/git fetch'. The base .git/config file looks like this:

      [core]
      repositoryformatversion = 0
      filemode = true
      bare = false
      logallrefupdates = true

      However, cloning this same repo using the Jenkins plugins yields the following base config file:

      [core]
      symlinks = false
      repositoryformatversion = 0
      filemode = true
      logallrefupdates = true

      The result is that our symlinks end up being local text files with references to the file it's supposed to link to, so those builds fail.

      This appears to be a similar issue to https://issues.jenkins-ci.org/browse/JENKINS-21168, except on the Linux platform. I don't believe core.symlinks should be set at all on Linux, generally speaking.

      I tried starting the slave agent with JAVA_ARGS=-Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true

      but I get the same results.

      If I'm reading the Windows version of this bug correctly, I think it's using JGit to create the initial repo, regardless of what we set in the JAVA_ARGS. Perhaps the bug lies there.

      It's also worth noting that we don't even have a JGit instance defined.

      We've worked around it by not using the git/git-client plugin and cloning our repos on these jobs using explicit git commands in our execute shells. Will consider downgrading plugins if it's not an easy/quick fix.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                markewaite Mark Waite
                Reporter:
                mjanulewicz Matt Janulewicz
              • Votes:
                2 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: