Question 183819 in CentOS Question posted in
The official documentation can be found here.

Centos – Jenkins pipeline from scp throws stderr: fatal: not in a git directory

We upgrade to "Jenkins 2.387.2" recently and started seeing below error for all the jenkins pipeline where we were using Jenkinsfile from git scm.

hudson.plugins.git.GitException: Command "git config remote.origin.url [email protected]:jenkinsci/pipeline-examples.git" returned status code 128:
15:33:37  stdout: 
15:33:37  stderr: fatal: not in a git directory
15:33:37  
15:33:37    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2732)
15:33:37    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2658)
15:33:37    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2654)
15:33:37    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1979)
15:33:37    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1991)
15:33:37    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.setRemoteUrl(CliGitAPIImpl.java:1599)
15:33:37    at hudson.plugins.git.GitAPI.setRemoteUrl(GitAPI.java:161)
15:33:37    at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:393)
15:33:37    at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:219)
15:33:37    at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:118)
15:33:37    at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:70)
15:33:37    at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:312)
15:33:37    at hudson.model.ResourceController.execute(ResourceController.java:101)

when I use pipeline code directly in the job, It works fine and all git operations works fine in the pipeline as well.

Git client plugin (git-client): 4.2.0
Git plugin (git): 5.0.2

Jenkins is running in kubernetes and the agent is running in pod. Even for fresh pipeline, I am able to reproduce this. This is only happening when I use pipeline code from SCM.

Any idea what’s wrong here?

Update 1 :

What I tested is, I created a fresh instance of Jenkins from the same version (2.387.2) and ran the same job and it works fine. So look like there is some issue with my jenkins only.

Update 2 (Workaround):

I found the issue similar to what mentioned here . So I tried to switch to a centos based image jenkins/jenkins:lts-centos7-jdk11 and it worked. I was using jenkins/jenkins:lts-jdk11 before which is debian based image. I am still not sure why centos and debian images behave differently with EFS filesystem.

Tags:

3

Answers


  1. Chosen as BEST ANSWER
    0

    TLDR: This is just a workaround. Change you base image to centos7

    I found that this is happening since i moved to EFS based storage class for my jenkins home mount. The issue was not observed with gp2 and ebs volume mounts. The issue is disussed in some detail here. I can't update the csi driver so i tried changing the base image. When I use a centos7 based image, Git checkout works properly.


  2. 0

    I’d post this as a comment to the question but my account is too new.

    Check the file ownership in the persistent volume. I don’t know if my situation is similar to yours. I’m running a Kubernetes cluster with a single worker agent and using local storage for my persistent volume.

    I ran into the same error on a jenkins:lts pod on Kubernetes. I had previously copied the mounted volume files in the Kubernetes node, recreated the persistent volume and pod, and "restored" back my earlier copy. In the process, it seems that the permissions were changed so that root was the owner of the files in the volume (I used sudo when making the copy). I changed the ownership back to the Kubernetes user and I was able to run my job successfully again.

    Login or Signup to reply.
  3. 0

    The reason centos7 image is working is because it’s using an old version of git.

    $ docker run -it jenkins/jenkins:lts-jdk11 git --version
git version 2.30.2

$ docker run -it jenkins/jenkins:lts-centos7-jdk11 git --version
git version 1.8.3.1

    Command line git included in recent container images includes a fix for a security issue. Command line git now refuses to perform operations in repositories when the directory is not owned by the current user.

    Command line git has decided that it is dangerous to perform git operations in a directory owned by a different user. I may consider a way to better detect it and better alert the administrator that there is a problem, but ultimately it is a mistake to perform git operations in a directory owned by a different user without intentionally configuring the safe.directory to allow it.

    centos7 is going to be retired on November 2023 and Jenkins shows a warning to upgrade to different OS.

    If you wish to circumvent the newly introduced security checks (I should point out that they’re probably implemented for good reason and it’s generally not recommended to disable them 😅), you have the option to execute the following command:

    git config --global --add safe.directory "*"

    You can run this command within any git repository on the Jenkins master.

    Alternatively, you can achieve the same effect by creating a ~/.gitconfig file with the following content:

    [safe]
    directory = *

    I found that this solution resolved the issues I was encountering with Jenkins, which had been deployed via this helm chart and was running on AWS EKS with EFS mounting.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search