Funtoo:Metatools/Advanced Usage/Gitolite Setup

Overview

For our local development setup, we will be using gitolite. Gitolite will make things quite a bit easier by managing git repositories for us. Think of gitolite as your own private GitHub that has no Web user interface (we modify its settings by pushing to its special gitolite-admin repo) and you'll have a pretty good idea of what gitolite does. To keep things simple, we will be using a single development system in our setup example below. However, because gitolite can be accessed over the network, you can easily set up gitolite on another system on your LAN or a remote system on the Internet and securely access it simply by modifying the git URL.

   Important

This document assumes you have basic knowledge of ssh-keygen and how to generate public/private SSH key pairs. If you don't know how to to this, see Generating SSH Keys for quick steps or OpenSSH Key Management, Part 1 for a more detailed introduction. For this article, you'll probably want to generate a private keys without a passphrase, which is more convenient but a much greater security risk if the private key gets compromised, or one with a passphrase but using keychain to manage ssh-agent for you.

Gitolite

Installation

To set up gitolite, we will use a repos user on your local development system. On this system, perform the following steps as root:

repohost # useradd -m repos

The repos user will be a dedicated user account on the system that will have gitolite enabled and will house our git repositories. Now, we are going to su to this new user and perform gitolite configuration:

repohost # su --login repos
user $ git clone https://github.com/sitaramc/gitolite
user $ install -d ~/bin

Now, as the repos user, add the following within your ~/.bashrc file:

   ~/.bashrc

export PATH=$HOME/bin:$PATH

What we're doing is setting up a bin directory where the gitolite command will be installed, which will be in your path, so that you can use it more easily. With this done, perform the following steps:

user $ source ~/.bashrc
user $ gitolite/install -ln

Now, your repos account is almost ready to be used for hosting repositories. The way gitolite works is that it is going to basically take over ssh access to the account, so that when you connect via ssh with git, it will perform its own authentication. For this to work, you will need to enable your own "master key" to access gitolite.

To do this, you'll want to decide from which account you'll want to administer gitolite itself. I prefer to use my "drobbins" account on local system, so I will copy my ssh public key from ~/.ssh/id_ed25519.pub to /var/tmp/drobbins.pub, and then perform the following steps to "prime" gitolite with this admin public key -- do this as the repos user:

user $ gitolite setup -pk /var/tmp/drobbins.pub

Gitolite will now be initialized to recognize the drobbins account as an administrator, which will allow this account to clone from repos@localhost:gitolite-admin and push any changes to this special git repository which contains the master configuration for gitolite. This is important because we will be performing the rest of gitolite setup over ssh, using this account.

   Note

OK, gitolite is installed! From this point forward, we will be using the drobbins (or equivalent) account on your development workstation to configure gitolite.

   Note

If you are setting up gitolite on a separate server, and assuming you have ssh properly configured, it would be prudent at this point to test the connection to the remote server from your local workstation . Perform ssh -T, or ssh test command appropriate to your setup, as shown below to verify you can connect:

user $ ssh -T repos@remote-server-name

You should receive confirmation message similar to:

hello repos, this is repos@remote-server-name running gitolite3 v3.6.11-3-g39293e6 on git 2.19.1

 R W	gitolite-admin
 R W	testing

If you receive the following message during testing:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
...

then localization settings for the remote server have not been completed. If remote server is Funtoo-based, complete the steps on the page Funtoo Linux Localization on the remote server.

gitolite-admin Clone

Now that gitolite is ready under the repos user on your local system, we can configure the rest by cloning the gitolite-admin repo and commiting configuration changes to it. I am going to use the drobbins account on the same system to do this, and you will use whatever account is associated with the public key you loaded into gitolite. I like storing my development repos in ~/development , so I'll go ahead and clone the gitolite-admin repo to that location so it can live along all my other git repos. Feel free to put this git repo wherever you like to store git repos that you develop on:

user $ cd ~/development
user $ git clone repos@localhost:gitolite-admin
user $ cd gitolite-admin

We are now ready to configure gitolite. We'll do this by modifying conf/gitolite.conf in the git repo and adding new ssh public keys to keydir/ as needed. You will see that the initial public key you used to "prime" gitolite already exists in keydir/. Once we change the configuration, and potentially add new public ssh keys that we want to grant access to gitolite-managed repositories, we'll perform a git commit and git push, and if gitolite doesn't complain about our changes, they'll take effect immediately. We'll go through our initial configuration steps below.

gitolite Configuration

Since I will be generating meta-repo and kits using my drobbins user, this account will need to have permissions to create repositories in gitolite. We're ready to edit conf/gitolite.conf so that it looks like this:

   gitolite.conf

# Group definitions below, starting with @. This makes it easy to associate multiple ssh keys with a particular person.

# Admins will have full control over gitolite.
@admins = drobbins

# Developers will be able to create, read and write git repositories.
@developers = drobbins

# Users will have read-only access.
@users = drobbins

# repositories:

# SPECIAL ADMIN REPO BELOW -- modify with care! 

repo gitolite-admin
    RW+     =   @admins

# AUTO-CREATED (wild) REPOS: gitolite will auto-create repos under wildrepo/ for us
# upon initial clone of any path within, if the repo doesn't already exist.

repo wildrepo/..*
    C       =   @developers
    RW+     =   @developers
    R       =   @developers @users

Now, we will want to commit and push our changes in the gitolite repo so they take effect -- This is how gitolite configuration changes are applied:

user $ git add .
user $ git commit -a -m "Initial setup"
user $ git push
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 12 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 607 bytes

Configuration

Now that merge-scripts is cloned, we will need to create a ~/.merge configuration file. Here is an example file that can serve as a starting point. In this example, developer bcowan has forked the kit-fixups repository on code.funtoo.org, and wants to test his personal changes by generating a complete meta-repo of his own:

   /root/.merge

[sources]

flora = https://code.funtoo.org/bitbucket/scm/co/flora.git
kit-fixups = ssh://git@code.funtoo.org:7999/~bcowan/kit-fixups.git
gentoo-staging = https://code.funtoo.org/bitbucket/scm/auto/gentoo-staging.git

[destinations]

# This is the key setting that tells merge-kits to push up to our local repo-space:
base_url = repos@localhost:wildrepo/staging

[branches]

flora = master
kit-fixups = master
meta-repo = master

Sources Section

Let's walk through this configuration file. The [sources] section defines locations of repositories that the merge scripts will use as sources for creating kits and meta-repo. In the above sample config, we are using the official Flora repository from Funtoo, and the official gentoo-staging repository used by Funtoo, but we are using our own fork of kit-fixups, which will allow us to add new ebuilds that will appear in kits, such as bug fixes to existing ebuilds in kits, as well as security fixes. For a core Funtoo Linux developer, this is a good way to start. If you are more interested in contributing third-party ebuilds, then you may instead choose to create your own fork of flora, and use our standard kit-fixups repository. Or, you could choose to create forks of both. The recommended best practice is to use our upstream repos when possible, and fork only those repos you want to customize. This way, you'll ensure that you have the most up-to-date versions of ebuilds in those unforked repos.

Branches Section

The [branches] section is used to define the default branches that are used by the merge-scripts. In general, sticking with master is fine, but if you need the flexibility, you can point the merge scripts to a particular feature branch to use instead, for example.

Work Section

The [work] section is used to define paths where the merge-scripts will do their work. The source and destination settings above are good defaults, and define where the merge-scripts will clone source repositories and destination (written to) repositories, such as kits and meta-repo. These are kept in two separate hierarchies so they don't get mixed up.

Generating New Kits

With this all configured, you are ready to generate new kits. These kits will be generated as root on your development system, and will be pushed up to repos@localhost/staging/repo_name. You will want to do this as your own user account, not as repos and not as root.

user $ merge-kits 1.4-release

merge-kits will proceed to create new kits and meta-repo, and will push them up to repos@localhost:wildrepo/staging/meta-repo, repos@localhost:wildrepo/staging/core-kit, etc. This process can take quite a while but has been optimized to run quickly on multi-core systems and use caching extensively so successive runs will complete quickly.

Using New Kits

Now that the new meta-repo and kits are created, here's how you'll use them on an existing Funtoo system, instead of your official Funtoo meta-repo and kits. First, we'll want to modify /etc/ego.conf as follows:

   /etc/ego.conf

[global]

sync_user = drobbins
sync_base_url = repos@localhost:wildrepo/staging/{repo}

# Yes, you are supposed to have a literal "{repo}", above. Ego recognizes this special pattern.

# You can have whatever [kits] section you want, below...

Since we are syncing as a regular user, we will need to make sure that our user account is in the portage group and that /var/git is writable by, in this case, drobbins:

root # chmod g+rwx /var/git

Let's also move the current meta-repo out of the way -- you can also simply delete the existing meta-repo. And then we'll re-run ego sync:

root # cd /var/git
root # mv meta-repo meta-repo.official
root # exit
user $ ego sync
Running as regular user.
Syncing meta-repo
Cloning into '/var/git/meta-repo'...
X11 forwarding request failed on channel 0
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 13 (delta 1), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (13/13), done.
Resolving deltas: 100% (1/1), done.
Syncing browser-kit branch 1.4-release

You will note a lot of failures at the end of sync that look like this:

ERROR: There was an error syncing qt-kit (error code True)
ERROR: There was an error syncing ruby-kit (error code True)
ERROR: There was an error syncing science-kit (error code True)
ERROR: There was an error syncing security-kit (error code True)
ERROR: There was an error syncing text-kit (error code True)
ERROR: There was an error syncing xfce-kit (error code True)
ERROR: Sync not successful.

This is just a cosmetic issue and as long as /var/git/meta-repo exists and the git clones themselves went fine, you should have a custom meta-repo on your system, ready to use!

If you type emerge -auDN @world, ego will now be using your custom kits, rather than the official Funtoo ones. This means that you can perform a variety of things you couldn't before. You can now add your own custom ebuilds to your fork of kit-fixups, and merge-kits will automatically incorporate these changes into your own custom kits. This will allow you to locally test any changes before submitting them as pull requests to Funtoo. You will also be able to maintain your own meta-repo and kits with your own local modifications, and have your systems use these meta-repo/kits instead of the official Funtoo ones.

Using New Kits with Metro

Rather than using new kits on a local Funtoo Linux system, you may want to use the kits to perform a metro build. This is desirable when you may want to use metro to perform continuous integration by attempting to perform a full stage1, 2 and 3 build, which is what the steps in this example accomplish, or simply test some hypothetical changes to the tree before creating a PR. Let's look at how to do this.

First, since metro runs as root, you will need to ensure that the root user on your local system has read access to gitolite. Perform the following steps:

root # cp /root/.ssh/id_ed25519.pub /var/tmp/root.pub
root # exit
user $ cd ~/development/gitolite-admin/keydir
user $ cp /var/tmp/root.pub .
user $ git add *

Now, give the root.pub key the ability to have read-only access to the repository (showing only the changes required):

   ~/development/gitolite-admin/conf/gitolite.conf

@users = drobbins root

Now, commit changes:

user $ git add .
user $ git commit -a -m "gitolite config updates"

Now, the root user, which is used by Metro to perform the ego sync, should be able to connect to the repository.

Next, we will want to instruct Metro to grab the custom meta-repo instead of the official one. To do this, first set up Metro on your system. Then, prior to running metro, set the EGO_SYNC_BASE_URL in your environment as follows:

root # export EGO_SYNC_BASE_URL="repos@localhost:wildrepo/staging/{repo}"

Metro should grab these settings and automatically adjust the ego.conf it uses based on these settings, to grab your meta-repo instead of the official one. You should now be able to perform local or CI testing of your changes. It's always a good idea to put this setting in ~/.bashrc of a CI user account so that it is always set correctly.