Difference between revisions of "Funtoo:Metatools/Advanced Usage"

From Funtoo
Jump to navigation Jump to search
Line 6: Line 6:


Once gitolite is set up, we will use use a variety of source repositories from Funtoo Linux to generate our own meta-repo and kits, which we can then test using [[Metro]]. This process is totally automated by the Funtoo Linux [https://github.com/funtoo/merge-scripts merge scripts].
Once gitolite is set up, we will use use a variety of source repositories from Funtoo Linux to generate our own meta-repo and kits, which we can then test using [[Metro]]. This process is totally automated by the Funtoo Linux [https://github.com/funtoo/merge-scripts merge scripts].
{{Note|This document assumes you have basic knowledge of {{c|ssh-keygen}} and how to generate public/private SSH key pairs. If you don't know how to to this, see [[Funtoo Containers#Generating SSH Keys|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  ==
== Gitolite  ==

Revision as of 00:20, May 20, 2018

This page documents how to set up a local development environment that will allow full local testing of changes. This includes generating your own meta-repo and kits with your custom changes, as well as getting metro set up for unit tests.

Overview

For our local development setup, we will be using gitolite on our development workstation. Gitolite will make things quite a bit easier by managing git repositories for us. Think of it 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.

Once gitolite is set up, we will use use a variety of source repositories from Funtoo Linux to generate our own meta-repo and kits, which we can then test using Metro. This process is totally automated by the Funtoo Linux merge scripts.

   Note

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 on your LAN, first choose a system that will be used to house your meta-repo and kits git repositories. This can be done locally, on the same system you will be using for testing (and even development), or you can set it up on a dedicated system. It's actually fine to set this up anywhere on the Internet, as git will use ssh to access this repository, but for the purposes of this article, we're assuming you're setting it up somewhere on your LAN.

On this system, perform the following steps as root:

root # 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:

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

Now, as the repos user, add the following to the end of your ~/.bashrc file:

   
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 my development workstation, so I will copy my ssh public key from ~/.ssh/id_rsa.pub to /var/tmp/drobbins.pub on the gitolite system, and then perform the following steps to "prime" gitolite with this admin public key:

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

Gitolite will now be initialized to recognize the drobbins remote account as an administrator. This is important because we will be performing the rest of gitolite setup over ssh, using this account.

Setup

Now that gitolite is ready, we can do everything else remotely. I am going to use the drobbins account on my development workstation, and you will use whatever account is associated with the public key you loaded into gitolite. I like storing my development repos in /var/src, so I'll go ahead and clone the gitolite-admin repo to that location so it can live along all my other git repos:

user $ cd /var/src
user $ git clone repos@repohost: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/.