Git ls-remote not returning data in RHEL

1.6k views Asked by At

We are working on a project in which all the dev environments are running Ubuntu 14.04 instances using Vagrant. Our CI build and deployment servers are running RHEL 6.5. We are using DUO to build Nodejs components and at build time, we programmatically clone dependencies from git urls. We have found this works all the time on Ubuntu, but hangs on RHEL. When we looked more closely, we found a problem with the following command:

git ls-remote --tags --heads https://<username>:<authtoken>@github.com/<path-to-repo>

This returns no data when it is run on our build server instances but works fine on our Ubuntu.

To debug, I used an RHEL instance in the cloud and found I could fix the problem by upgrading from the 1.7.x version of git that comes OTB with RHEL to 1.9.4. But that did not work on the build instances. I cannot see any difference in the git config for the two instances. Since I don't have regular access to the build servers, I found a Centos image where I could reproduce the problem. I have stripped down the git config settings on that and on my ubuntu image so they are identical. I cannot see what is causing the problem.

Any ideas?

1

There are 1 answers

0
Scheiner On

After some time, we worked out what we think is an answer to this. When you install git 1.7 through yum, you get a dependency, perl-Git. The initial problem we had was that under 1.7 we got a password prompt when downloading git repo components with a github token. This was obviously a problem in a CI context as no one would be there to type in the password.

That initial problem was resolved by upgrading to a more recent version of git, in our case, 1.9.4, which we built from source. That was where the problem mentioned in this post came in where git ls-remote returned nothing. That problem went away when we removed perl-Git which remained from the old 1.7 install.

We had hoped to build 1.7 from source and install without perl-Git to see whether all problems went away, but we ran out of time. So for now, we believe the answer is in a conflict with that perl-Git package.