Tag Archives: git

Connecting Jenkins on Windows to Git

Setting up connection from Jenkins/Hudson to your Git server shouldn’t be any problem if the CI server is running on Linux, but achieving the same from Windows seems to be little trickier. The problem I encountered was that any build I tried to execute hang forever right on the start trying to obtain sources from the repository.
Googling around I found some suggestions to run Jenkins server on a dedicated user account and put private SSH key into proper directory. Unfortunately, that didn’t work. Without going into more details I’d just recommend you to keep Jenkins running as a service by the system user.
Assuming that Jenkins has the Git plugin properly installed and your build is configured, there are two key things that you need to do:

known_hosts

This file contains fingerprints of external ssh hosts. Each entry means a “trusted” host. Without it, ssh shows a warning during connection and prompts you for action, which exactly the reason why Jenkins build hangs on connection to Git server.

To create such file you can, for example, execute “ssh targethost” in your console (or connect using putty), answer “yes” and get known_hosts from your home/.ssh Next, put it in your Git client’s .ssh subdirectory (create one if necessary). In my case it was:

C:\Program Files (x86)\Git\.ssh\known_hosts

Private ssh key

I assume that you already know how to generate a pair of RSA public/private key and the public key to your Git server configuration. The important thing that you need to do in order to make the pair work properly for Jenkins is, similarly to known_hosts, to put your private key in Git .ssh subdirectory and name it “id_rsa”:

C:\Program Files (x86)\Git\.ssh\id_rsa

Voilà. Try now to execute your build, it should download sources.

Advertisements

git-svn vs Maven Build Number plugin

Recently I joined a project with sources hosted on external Subversion server. Migration to Git is out of the question since the central repository is located in different country and used by many teams from departments spread all over this international corporation. Fortunately, there’s “git-svn” tool which can provide many great Git features. After setting it up I initialized my repo, downloaded the latest revision and launched Maven build. Surprisingly, it exploded with following error message:

Provider message:
The svn command failed.
Command output:
svn: ‘.’ is not a working copy

[INFO] ————————————————————————
[ERROR] BUILD ERROR
[INFO] ————————————————————————
[INFO] Cannot get the revision information from the scm repository :
Error!

After quick investigation (mainly scouring through lenghty POM hierarchy) I found the culprit:

Maven Build Number plugin

This plugin gives many possibilities of generating build numbers as variables and then use them for any purpose. In my case, the plugin was included only to obtain the last svn revision number and store it in some variable. Then the value supposed to be put in .war Manifest file. Since I downloaded the sources via “git svn” there was no .svn directory anywhere and the plugin refused to work, so it terminated the whole build.

Solution

There are many options to avoid this problem, for example disabling the plugin in POM file or removing it entirely. Such methods are, however, too invasive and I didn’t want to mess with project configuration, even if it’s only on my machine. We all know that such “temporary” modifications are very likely to be eventually accidentally committed to central repo with painful consequences. Having that in mind, I went with another trick.

Silencing plugin from the inside

I downloaded source code of Maven Build Number plugin and erased most of it, leaving empty mojos with no bodies in execute() methods. Then I built it and replaced the original plugin in local maven repo with my “dummy”. Next, I launched the main project build and noticed no more svn errors. Everything went smoothly

The cost

The cost of my tinkering is of course invalid revision number in the Manifest file but I don’t believe it has any relevance for me during the development. Let the Continuous Integration server use it and save it, I am totally happy with my option.

What next?

There could be a distinction between different build types with possibility to switch them with Maven profiles. However, it adds some complexity for every person using the project, which I would like to avoid. I seem satisfied that the problem has been resolved quickly and without touching the project itself, so I can focus back on  coding.