Gitolite is a wrapper around a base git installation which facilitates the secure management of project repositories and of the user privileges governing access to those repositories. Its simple configuration is well documented in a short README in the distribution. Essentially, those sys-admins charged with administration of the central git installation clone the gitolite configuration directory, make their changes to the configuration files and push those back to origin. A post-commit hook in the gitolite installation deploys the new configuration, creating and modifying project repositories as required and installing, revoking or updating the keys for authorized users as appropriate.
The gitolite configuration consists of conf/gitolite.conf used to define project repositories and the group and user privileges which apply to it; and a directory of ssh public keys in the form: keydir/User_name.pub.
The security model depends on the creation of a single user with privileges over the git installation and the project repositories it hosts. By default, this user is called git. Only the git user may interact with the projects.
The user privilege model is built on ssh key pairs. Each developer or tester with need for access to a project repository hosted by gitolite generates a key pair, traditionally done using ssh-keygen, and provides their public key (.ssh/id_rsa.pub by default) to the administrator of the repository. The gitolite administrator then adds the public key to their cloned gitolite configuration, runs `git add keydir/new_user.pub` then `git commit` then `git push origin` to enable the new user.
The syntax used in conf/gitolite.conf is documented in the linked README above.
Integrating Jenkins with Gitolite
Applying what we no know of the Gitolite architecture then requires the following steps:
generate an ssh key-pair
Generate an ssh key-pair with an empty passphrase on the jenkins server for the jenkins server
It is important to use an empty passphrase, or the CI server will pause until it times out waiting for the entry of the passphrase.
Next harvest that public key for the next step:
create a gitolite user for jenkins
create a gitolite user for jenkins like so:
Paste the jenkins public key into this file, ensuring that it is on a single line, collapsing line feeds if it wrapped when you pasted it into the file.
extend privileges to the jenkins user to each relevant project repository
Extend privileges to the jenkins user to each relevant project repository like so:
Read only privileges are sufficient to permit jenkins to clone the directory.
push changes to gitolite configuration
push changes to gitolite configuration like so:
add /etc/hosts entry for git repository
If the same IP hosts both gitolite and jenkins, you next want to add an entry to /etc/hosts for the git repository on the jenkins server.
add gitolite ssh fingerprint to jenkins' .ssh/known_hosts
Add the gitolite repository's ssh fingerprint to the jenkins user's .ssh/known_hosts file in their home directory on the jenkins' server like so:
Make sure you clean up after the fingerprint is captured, so you are ready for the next build.
configure the git credentials in jenkins for the Project
Configure the git credentials in Jenkins for the Project. If the gitolite and jenkins installations are hosted at the same IP and you set up the entry in /etc/hosts, then you can use the same credentials and url as you would to clone the project in your local sandbox. Otherwise you will need to repeat the .ssh/known_hosts step above for localhost or 127.0.0.1.