Hi,
Upgrading GIT on Jenkins Master (Windows Server 2016) from Git-2.29.2.2-64-bit 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:
stdout:
stderr: fatal: not in a git directory
Regards
Pramod
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
Hi,
I had even reverted back all changes only this change is causing this issue.
Reverting GIT for Windows to Git-2.29.2.2-64-bit there are no issues
Apart from Jenkins and Plugin update there are no other changes.
Regards
Pramod
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 '*'
and
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.
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.