Skip to content


Gitlab is installed via Ansible. During the installation, the password for the administrative "root" user is set to the Ansible variable gitlab_root_user_password, which is saved in the pass password-store.

Any further configuration is made using the Gitlab Webui, not Ansible. Gitlab is a bit hard to automate using Ansible, and it is mostly not required to automate it.

Gitlabs documentation can be found here.

Granting employees access to Gitlab

Access to the Gitlab is managed via Gitlabs own authentication system. In order to add a new user to it, please refer to the official gitlab documentation on how to add users as well as the official gitlab documentation on how to manage project group members. Signup is disabled on Gitlab installed with Blunix Stack by default, so only administrators can create new users.

In case your companies Gitlab WebUI is not reachable over the public internet, please also refer to the documentation on how to open the firewall for specific employees to connect to the Gitlab system over the wireguard VPN.

Adding Gitlab Runners

  • Follow the instructions in the Gitlab Runner documentation to obtain a Gitlab Runner token
  • Setup a gitlab_runner_registration_token Ansible variable for the specific host like so:
# Add the runner token to the password store
pass edit my_new_runners_inventory_hostname_gitlab_runner_registration_token

# Add to playbook-infrastructure-company/inventory/host_vars/my-new-runners-inventory-hostname.yml
gitlab_runner_registration_token: "{{ my_new_runners_inventory_hostname_gitlab_runner_registration_token }}"
  • Run the Ansible play playbook-infrastructure-company/plays/utilities/gitlab-runner.yml against a new server.

The Gitlab Runner should then show up in the Gitlab WebUI.

Automatic Gitlab upgrades

Gitlab upgrades are done daily with an upgrade script:

root@cus-util-prod-git-1 ~ # cat /etc/cron.d/upgrade_gitlab 
# Ansible: upgrade_gitlab
0 4 * * * root /usr/bin/prom-cron upgrade_gitlab /etc/gitlab/

Every couple of versions gitlab requires manual intervention to complete an upgrade. In this case the cronjob script will trigger output, which will be send to your monitoring matrix channel. You should then ssh to the gitlab server and try to trigger the upgrade - it will fail with an error message that usually documents well what steps to take to upgrade to the higher version.

For more information see below.

Manually upgrading Gitlab

While upgrading Gitlab, before an upgrade to the next major version is possible, the previous minor version has to be installed first. An example:

# Show the current installed Gitlab version
root@cus-util-prod-git-1 ~ # apt-cache policy gitlab-ce
  Installed: 15.11.8-ce.0
  Candidate: 15.11.8-ce.0
  Version table:
     16.1.0-ce.0 500
        500 buster/main amd64 Packages
        100 /var/lib/dpkg/status
     16.0.5-ce.0 500
        500 buster/main amd64 Packages
     16.0.4-ce.0 500
        500 buster/main amd64 Packages
     16.0.3-ce.0 500
        500 buster/main amd64 Packages
     16.0.2-ce.0 500
        500 buster/main amd64 Packages
     16.0.1-ce.0 500
        500 buster/main amd64 Packages
     16.0.0-ce.0 500
        500 buster/main amd64 Packages
     15.11.9-ce.0 500
        500 buster/main amd64 Packages
 *** 15.11.8-ce.0 500
        500 buster/main amd64 Packages
     15.11.7-ce.0 500
        500 buster/main amd64 Packages

Version 15.11.8-ce.0 is currently installed. In order to upgrade to the latest version 16.1.0-ce.0, we have to upgrade to the latest 15. version:

root@cus-util-prod-git-1 ~ # apt-get install gitlab-ce==15.11.9-ce.0

And then upgrade to the latest 16. version:

root@cus-util-prod-git-1 ~ # apt-get install gitlab-ce==16.1.0-ce.0