-
Bug
-
Resolution: Postponed
-
Major
-
VMWare environment: kernel 2.6.32-100.37.1.el6uek.x86_64
With the previous version of the plugin, I am able to run and select a specific folder from my Git repository to run a suite of tests on. However, with the newer version, I receive this message:
Command "git fetch -t origin +refs/heads/:refs/remotes/origin/" returned status code 128:
stdout:
stderr: R access for project1 DENIED to jenkins
(Or there may be no repository at the given path. Did you spell it correctly?)
fatal: The remote end hung up unexpectedly
I thoroughly perused my configuration settings, and they're all told to point to git@git.repository.internal.com, hence use the user git.
The only fix was to revert to the previous version.
[JENKINS-16937] GIT 1.2.0 authenticates as the wrong user
The git-plugin 1.2.0 and its matching git-client-plugin version used JGit as their default Git implementation. The JGit implementation is not sufficient for the many use cases supported by the Jenkins Git plugins.
The git-client-plugin 1.0.5 and git-plugin 1.3.0 versions switch back to using the command line Git as their default Git implementation. Could you upgrade to those versions and see if the issue is resolved for you?
If it is not resolved, then the issue may be related to the refactoring that was started in 1.1.27.
When I upgraded to 1.2.0, I saw some similarly bizarre behavior. It was suddenly trying to clone from the wrong url. The url it referred to was our old git server which has been gone for 6 months. Downgrading made the problem go away. I could not figure out where it was getting this data from, but it seems like the new plugin is perhaps getting config data differently than before.