0

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?

Scheiner
  • 87
  • 1
  • 6
  • Try running with `GIT_TRACE=2 GIT_TRACE_PACKET=1 git ...`, this will cause git to provide more debugging information. `GIT_TRACE_PACKET` should provide more information about the communication between the client and server. Hopefully, it can clue you in to the issue and get it fixed. – John Szakmeister Sep 05 '14 at 17:21
  • I tried that on both images. On the RHEL one that works, got a series of traces showing the commands and then all the packets for the changesets coming back from git. On the Centos image that doesn't work, I see the first two commands, then nothing. Nothing goes out, nothing comes back in: `trace: built-in: git 'ls-remote' '--tags' '--heads' 'https://:@github.com/visionmedia/superagent' trace: run_command: 'git-remote-https' 'https://:@github.com/visionmedia/superagent' 'https://:@github.com/visionmedia/superagent'` – Scheiner Sep 06 '14 at 08:56
  • It looks to me like you have a network issue. It could be any number of things, but I doubt it's specific to Git. Is DNS working from the build server? Is traffic allowed from the build server to GitHub? You could try using openssl to connect to GitHub, to confirm this. The command, `openssl s_client -connect github.com:443`, should show you GitHub server's certs. If you can't connect at that level, then there's no question about it being a network problem. – John Szakmeister Sep 06 '14 at 11:25

1 Answers1

0

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.

Scheiner
  • 87
  • 1
  • 6