Upgrading GIT on Jenkins controller causing failures for MultiBranch pipelines


Upgrading GIT on Jenkins Master (Windows Server 2016) from Git- to Git-2.37.1-64-bit is causing below issue for Jenkins Multi Branch Pipeline

git config remote.origin.url returned status code 128:

stderr: fatal: not in a git directory


It is quite unlikely that an upgrade of command line git is the root cause of that change. Check for other changes that happened at roughly the same time.

it means the directory your running the command in is not a git repo. check pwd() to confirm your in the right directory


I had even reverted back all changes only this change is causing this issue.

Reverting GIT for Windows to Git- there are no issues

Apart from Jenkins and Plugin update there are no other changes.


Also i am not getting any workaround for this as once i downgrade the GIT version things works

There is no issue in configuration as downgrading GIT Pipeline works fine

You are free to choose to not upgrade command line git. I suspect that you’re seeing some other issue that you are mistakenly attributing to the command line git upgrade. It could be that you need to define a host key verification strategy if you’re accessing the repository with ssh. It could be that you need to perform some other change. I don’t know.

I’ve not seen a case in a very long time where an upgrade of command line git broke an interesting use case. I’m running command line git 2.37.1 on all my Windows computers without any issue. The ci.jenkins.io Windows agents are running command line git 2.37.1 on their agents. Other Windows agents in the Jenkins infrastructure are also running command line git 2.37.1. If there is a problem with command line git 2.37.1, then it is somehow quite special to your environment.

Hello, I can confirm the problem. I faced the same error after an automatic process upgraded git to “version 2.37.2.windows.1”. After manually upgrading to git “version 2.37.3.windows.1” the problem is gone.
I have no explanation…

I’m getting this error on a brand new install of Jenkins and I haven’t configured anything yet except a single pipeline task using SCM (not a script) to grab the Jenkinsfile but it never gets that far. Jenkins version 2.373 with Git 4.12.1

I’m using a self-signed cert on the server if that matters.

Never mind, I got it working. I’m not 100% sure exactly what I did to fix it unfortunately.

I logged into the console of the container from w/in Azure and ran the following to create a new ssh key:

ssh-keygen -t rsa -b 4096 -C "<my github login email>"

private key was saved in /var/jenkins_home/.ssh/id_rsa
public key was saved in /var/jenkins_home/.ssh/id_rsa.pub
After adding the SSH key to Github using the public key, I needed to add the Github credential to Jenkins
Create a system credential for SSH Username and Passphrase but for the key you’ll need to run this on the Jenkin’s server:

cat /var/jenkins_home/.ssh/id_rsa

I also ran
git config --global --add safe.directory '*'
ssh-keyscan github.com >> /var/jenkins_home/.ssh/known_hosts

On the Jenkins I configured the following for the pipeline:
Up near the top there is a “Github Project” checkbox that is easy to forget. I configured the project url.
Down below I chose pipeline script from SCM
I set the url and chose the github credentials I created
down below I chose “Githubweb” for the repository browser and set the url
At the bottom I set the script path to BlazorApp3/Jenkinsfile because my jenkins file was in the BlazorApp3 subfolder.
At the end I had the Lightweight Checkout disabled but I’ve since re-enabled it and the pipeline still works.

1 Like

I encountered the same issue, on Windows Server 2019, as Pramod. I installed Git-2.39.1 as part of building a new Jenkins server, and got the ‘not in a git directory’ error for pretty much any workflow that involves Git. Downgraded Git to 2.29 and everything is working as it should.

We’ve learned of a security fix that was applied to command line git. It now requires that the files in the .git folder must be owned by the user that is calling command line git. It is a safety measure to close a security vulnerability.

Update the ownership of the files on the agent and on the controller so that they are all owned by the user account that runs the Jenkins process.

Thank you, that does explain the behavior.

I have JENKINS_HOME on a NAS. Any files created as part of a pipeline in JENKINS_HOME get the owner set to the machine name of the server instead of the underlying user.

Looks like my best bet is to just stay on Git 2.29 for now. I want to keep JENKINS_HOME on the NAS for data resiliency and I don’t want to change the way it assigns file owners for fear of affecting other projects on the NAS.