The Gitlab overlay, originally the CVUT overlay, is currently on par with the latest GitLab version (13.8.4 as of January 2021). The repo and issues can be found here.
With version 13.8.3 the former www-apps/gitlabhq package was renamed to www-apps/gitlab. Since the gitlab core and gitlab-gitaly must neccessarily have the same version the former dev-vcs/gitlab-gitaly package was abandoned and gitlab-gitaly is now included in the www-apps/gitlab package.
By means of "Post Deployment Migrations" as described here starting with version 13.8.4 upgrading takes place without downtime (Nearly: The still required restart needs some time). This made the slots obsolete and so the upgrade procedure less complicated.
The migration from a www-apps/gitlabhq installation to a www-apps/gitlab one is supported by all www-apps/gitlab-13.8.x ebuilds. For more information read the 2021-02-10-gitlabhq-to-gitlab news message of the overlay.
To add using eselect repository:
eselect repository enable gitlab
emerge --sync gitlab
To add using layman:
layman -a gitlab
GitLab requires the use of a database backend. Since version 12 PostgreSQL is the only supported database.
U I - - favicon : For the Custom Favicon to work, GraphicsMagick needs to be installed - - gitaly-config : Config in /etc/gitlab (s. news 2021-02-22-etc-gitlab) - - gitaly_git : Use the Git version provided by Gitaly - - mail_room : Enables support for GitLab MailRoom + + puma : Enables support for the puma HTTP server - - unicorn : Enables support for the unicorn HTTP server + + systemd : Enable use of systemd-specific libraries and features like socket activation or session tracking
The gitaly-config USE flag is explained in the 2021-02-22-etc-gitlab news of the overlay. The gitaly_git USE flag uses the bundled Git from gitlab-gitaly instead of dev-vcs/git. The puma USE flag is preselected because with GitLab 12.9 Puma has replaced Unicorn as the default web server. The systemd USE flag is preselected since the maintainer of the overlay ran out of OpenRC hosts for init script testing. :-) But with the help of some users of the overlay the OpenRC init scripts will be provided further on.
Add the following keywords to be accepted by Portage (we use amd64 as architecture here; x86 is also available):
www-apps/gitlab ~amd64 dev-vcs/gitlab-shell ~amd64 www-servers/gitlab-workhorse ~amd64
From GitLab 13.6 on Ruby 2.7 or later is required. Until Ruby 2.7 will be stabilized one must add further keywords to be accepted. As of January 2021 these were the following versions:
=dev-lang/ruby-2.7.2 ~amd64 =dev-ruby/minitest-5.13.0 ~amd64 =dev-ruby/net-telnet-0.2.0 ~amd64 =dev-ruby/power_assert-1.1.7 ~amd64 =dev-ruby/rake-13.0.1 ~amd64 =dev-ruby/xmlrpc-0.3.0 ~amd64 =dev-ruby/rdoc-6.2.0 ~amd64 =dev-ruby/kpeg-1.1.0-r1 ~amd64 =virtual/rubygems-16 ~amd64 =dev-ruby/rubygems-3.1.4 ~amd64
The overlay overrides the gentoo acct-user/git package introducing a new USE flag gitlab which creates the git user as required by www-apps/gitlab with HOME in /var/lib/gitlab/ and as member in the redis group. Add the USE Flag:
echo "acct-user/git gitlab" >> /etc/portage/package.use/gitlabhq
Next emerge the package and follow the instructions given on the output (here the output of a 13.8.4 installation for an example).
emerge -av gitlab
... * For this new installation, proceed with the following steps: * * 1. Create a database user for GitLab. * On your database server (local ore remote) become user postgres: * su -l postgres * GitLab needs two PostgreSQL extensions: pg_trgm and btree_gist. * To create the extensions if they are missing do: * psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;" * psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS btree_gist;" * Create the database user: * psql -c "CREATE USER gitlab CREATEDB PASSWORD 'gitlab'" * Note: You should change your password to something more random ... * You may need to add configs for the new 'gitlab' user to the * pg_hba.conf and pg_ident.conf files of your database server. * * 2. Edit /etc/gitlab/database.yml in order to configure * database settings for "production" environment. * * 3. Edit /etc/gitlab/gitlab.yml * in order to configure your GitLab settings. * * 4. GitLab expects the parent directory of the config files to * be its base directory, so you have to sync changes made in * /etc/gitlab/ back to /opt/gitlab/gitlab/config/ by running * rsync -aHAX /etc/gitlab/ /opt/gitlab/gitlab/config/ * * 5. You need to configure redis to have a UNIX socket and you may * adjust the maxmemory settings. Change /etc/redis.conf to * unixsocket /var/run/redis/redis.sock * unixsocketperm 770 * maxmemory 1024MB * maxmemory-policy volatile-lru * * 6. Gitaly must be running for the "emerge --config". Execute * systemctl --job-mode=ignore-dependencies start gitlab-gitaly.service * Make sure the Redis server is running and execute: * emerge --config "=www-apps/gitlab-13.8.4"
Work through the list. Note that the database you specify in /etc/gitlab/database.yml will be deleted by the "Initializing database" step below! Finally run the configuration script (again with an example output).
emerge --config gitlab
... Configuring pkg... * Checking configuration files ... * Hit <Enter> to continue * Set the Administrator/root password: * * Set the Administrator/root email: email@example.com * Initializing database ... This will create the necessary database tables and seed the database. You will lose any previous data stored in the database. Do you want to continue (yes/no)? yes ... (messages from the database creation and initialization) * * Now start gitlab with * $ systemctl start gitlab.target * * You might want to check your application status. Run this: * $ cd /opt/gitlab/gitlab * $ sudo -u git ruby /usr/bin/bundle exec rake gitlab:check RAILS_ENV=production * * GitLab is prepared now. * To configure your nginx site have a look at the examples configurations * in the /opt/gitlab/gitlab/lib/support/nginx/ folder.
The Administrator password and email are used for the initial administrator account of the GitLab web application. In the above omitted "messages from the database creation and initialization" you'll find the login and password for this account. You should use a working email address as on startup GitLab will send an "Access to the GitLab Instance group was granted" mail to this address.
Now start GitLab, log in with the administrator account and adopt the default settings to your need.
GitLab expects the parent directory of the config files to be its base directory, so the config has to stay in /opt/gitlab/gitlab/config/. Symlinking /opt/gitlab/gitlab/config -> /etc/gitlab doesn't work as GitLab uses the real path of the config files to get the parent directory. In order to use the standard Gentoo way of managing config files, the config files are copied to /etc/gitlab/ where they are changed and then synced back to /opt/gitlab/gitlab/config/ by running:
rsync -aHAX /etc/gitlab/ /opt/gitlab/gitlab/config/
Note that the trailing slashes are important here!
The rsync command updates only those config files in /opt/gitlab/gitlab/config/ that exist in /etc/gitlab/, so it suffices to have only the changed ones in /etc/gitlab/.
rc-service gitlab start
rc-service gitlab status
Starting automatically at system boot:
rc-update add gitlab default
systemctl start gitlab.target
systemctl list-dependencies gitlab.target
Starting automatically at system boot:
systemctl enable gitlab.target
Run this command to get a full diagnostic.
bundle exec rake gitlab:env:info RAILS_ENV=production
bundle exec rake gitlab:check RAILS_ENV=production
NGINX is the oficially supported webserver for GitLab. If you cannot or do not want to use NGINX as your web server, see GitLab recipes. You have to set up a sites config for GitLab. See /opt/gitlab/gitlab/lib/support/nginx/gitlab-ssl for an example site configuration.
The web interface is available at the URL you configured in /etc/gitlab/gitlab.yml:
## GitLab settings gitlab: ## Web server settings (note: host is the FQDN, do not include http://) host: gitlab.<your-domain> port: 443 # Set to 443 if using HTTPS, see installation.md#using-https for additional HTTPS configuration details https: true # Set to true if using HTTPS, see installation.md#using-https for additional HTTPS configuration details
With the above the URL would be https://gitlab.<your-domain>.
The www-apps/gitlab ebuild will check if one is on a supported "Upgrade path" (see the upstream update README) to ensure that the requirements for "Upgrading without downtime" are met. The upgrade steps are:
emerge -u gitlab
... * Migrating database without post deployment migrations ... * * Update the config in /etc/gitlab and then run * rsync -aHAX /etc/gitlab/ /opt/gitlab/gitlab/config/ * systemctl restart gitlab.target * * To complete the upgrade of your GitLab instance, run: * emerge --config "=www-apps/gitlab-13.8.4"
If there are config updates (there were none in the above example output), run:
rsync -aHAX /etc/gitlab/ /opt/gitlab/gitlab/config/
The restart GitLab and do the database migrations with postdeployment migrations by executing:
emerge --config "=www-apps/gitlab-13.8.4"
* Migrating database ... * Clean up cache ... * Configure Git to enable packfile bitmaps ... * * You might want to check your application status. Run this: * $ cd /opt/gitlab/gitlab * $ sudo -u git ruby /usr/bin/bundle exec rake gitlab:check RAILS_ENV=production * * GitLab is prepared now. * You should check the example nginx site configurations in the. * /opt/gitlab/gitlab/lib/support/nginx/ folder * for any updates (e.g by diff with the previous version).