GitLab Runner on Uberspace

by Lorenz Bausch Posted on June 16, 2017

23.09.2017: Updated instructions for 10.0.x release of GitLab Runner.

This post describes how to setup gitlab-runner on an Uberspace using the shell executor.

Download gitlab-runner-linux-amd64

Download the Runner binary into the ~/bin directory and make it executable:

$ mkdir ~/bin
$ cd ~/bin
$ wget https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
$ chmod +x gitlab-runner-linux-amd64

$ mkdir ~/bin

$ cd ~/bin

$ wget https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

$ chmod +x gitlab-runner-linux-amd64

Create a working directory for the Runner:

$ mkdir ~/gitlab-ci

1	$ mkdir ~/gitlab-ci

Get configuration details for the Runner

In your GitLab project navigate to Settings > CI/CD Pipelines. Find the URL for the runner setup and the registration token as shown in the picture below:

Register the Runner

Provide the configuration details when asked and make sure to choose shell as executor:

$ ./gitlab-runner-linux-amd64 register
WARNING: Running in user-mode. 
WARNING: The user-mode requires you to manually start builds processing: 
WARNING: $ gitlab-runner run 
WARNING: Use sudo for system-mode: 
WARNING: $ sudo gitlab-runner... 
 
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.com/ci
Please enter the gitlab-ci token for this runner:
<TOKEN>
Please enter the gitlab-ci description for this runner:
[<DESCRIPTION>]: 
Please enter the gitlab-ci tags for this runner (comma separated):
<YOUR TAGS>
Whether to run untagged builds [true/false]:
[false]: 
Whether to lock Runner to current project [true/false]:
[false]: 
Registering runner... succeeded runner=wenFG1n6
Please enter the executor: docker, docker-ssh, parallels, shell, docker+machine, ssh, virtualbox, docker-ssh+machine, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

$ ./gitlab-runner-linux-amd64 register

WARNING: Running in user-mode.

WARNING: The user-mode requires you to manually start builds processing:

WARNING: $ gitlab-runner run

WARNING: Use sudo for system-mode:

WARNING: $ sudo gitlab-runner...

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

https://gitlab.com/ci

Please enter the gitlab-ci token for this runner:

<TOKEN>

Please enter the gitlab-ci description for this runner:

[<DESCRIPTION>]:

Please enter the gitlab-ci tags for this runner (comma separated):

Whether to run untagged builds [true/false]:

[false]:

Whether to lock Runner to current project [true/false]:

[false]:

Registering runner... succeeded runner=wenFG1n6

Please enter the executor: docker, docker-ssh, parallels, shell, docker+machine, ssh, virtualbox, docker-ssh+machine, kubernetes:

shell

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Create a daemon to start the Runner

Create a daemon to start your GitLab Runner automatically on reboot and have it supervised. See https://wiki.uberspace.de/system:daemontools for reference.

First, setup your service directory:

$ test -d ~/service || uberspace-setup-svscan

1	$ test -d ~/service \|\| uberspace-setup-svscan

Create a script called gitlab-ci inside your ~/bin directory. Note the exec command which prevents spawning a new process and allows the daemontools to fully control the Runner:

#!/usr/bin/env bash
exec ~/bin/gitlab-runner-linux-amd64 run --working-directory ~/gitlab-ci

1 2	#!/usr/bin/env bash exec ~/bin/gitlab-runner-linux-amd64 run --working-directory ~/gitlab-ci

Make the script executable:

$ chmod +x ~/bin/gitlab-ci

1	$ chmod +x ~/bin/gitlab-ci

Activate the daemon:

$ uberspace-setup-service gitlab-ci ~/bin/gitlab-ci
Creating the ~/etc/run-gitlab-ci/run service run script
Creating the ~/etc/run-gitlab-ci/log/run logging run script
Symlinking ~/etc/run-gitlab-ci to ~/service/gitlab-ci to start the service
Waiting for the service to start ... 1 2 3 4 5 6 started!

Congratulations - the ~/service/gitlab-ci service is now ready to use!
To control your service you'll need the svc command (hint: svc = service control):

To start the service (hint: u = up):
  svc -u ~/service/gitlab-ci
To stop the service (hint: d = down):
  svc -d ~/service/gitlab-ci
To reload the service (hint: h = HUP):
  svc -h ~/service/gitlab-ci
To restart the service (hint: du = down, up):
  svc -du ~/service/gitlab-ci

To remove the service:
  cd ~/service/gitlab-ci
  rm ~/service/gitlab-ci
  svc -dx . log
  rm -rf ~/etc/run-gitlab-ci

More information about controlling daemons can be found here:
https://uberspace.de/dokuwiki/system:daemontools#wenn_der_daemon_laeuft

$ uberspace-setup-service gitlab-ci ~/bin/gitlab-ci

Creating the ~/etc/run-gitlab-ci/run service run script

Creating the ~/etc/run-gitlab-ci/log/run logging run script

Symlinking ~/etc/run-gitlab-ci to ~/service/gitlab-ci to start the service

Waiting for the service to start ... 1 2 3 4 5 6 started!

Congratulations - the ~/service/gitlab-ci service is now ready to use!

To control your service you'll need the svc command (hint: svc = service control):

To start the service (hint: u = up):

svc -u ~/service/gitlab-ci

To stop the service (hint: d = down):

svc -d ~/service/gitlab-ci

To reload the service (hint: h = HUP):

svc -h ~/service/gitlab-ci

To restart the service (hint: du = down, up):

svc -du ~/service/gitlab-ci

To remove the service:

cd ~/service/gitlab-ci

rm ~/service/gitlab-ci

svc -dx . log

rm -rf ~/etc/run-gitlab-ci

More information about controlling daemons can be found here:

https://uberspace.de/dokuwiki/system:daemontools#wenn_der_daemon_laeuft

For details on how to manage a daemon see https://wiki.uberspace.de/system:daemontools#wenn_der_daemon_laeuft

That’s it!

Your GitLab Runner should now be ready to process your builds if your project is configured correctly. See https://docs.gitlab.com/ce/ci/ for reference.

Posted in git | Comments Off

Chrome 56: Install and use Extensions

by Lorenz Bausch Posted on March 1, 2017

Starting with Chrome 56 on Debian you might end up having no Extensions. To re-enable them again you have to start Chrome with

--enable-remote-extensions

1	--enable-remote-extensions

To make this a default add this flag to the default flags in /etc/chromium.d/default-flags:

# Enable extensions
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"

1 2	# Enable extensions export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"

Reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851927

Posted in Debian | Comments Off

Waiting for server to accept SSH connections

by Lorenz Bausch Posted on October 22, 2016

Sometimes you need to wait for a just booted server to accept SSH connections. This can be solved with a one-line bash script:

until nc -w 10 -z $SERVER_IP 22; do echo "SSH not available" && sleep 5; done

1	until nc -w 10 -z $SERVER_IP 22; do echo "SSH not available" && sleep 5; done

Posted in Debian, Ubuntu | Comments Off

npm install fails with “npm ERR! tar.unpack untar error”

by Lorenz Bausch Posted on April 25, 2016

Problem

npm failed randomly while installing packages. It didn’t matter which packages or if running on Debian itself or inside virtual machines using Ubuntu (vagrant). Upgrading npm to the latest version ( sudo npm install -g npm@latest ) and clearing npm’s cache ( npm cache clean ) didn’t help either.

After examining the downloaded temporary packages in /tmp I realized that they were corrupt. The corrupt packages changed randomly on every download attempt. Changing the temporary directory from /tmp to another location did not resolve the issue. Every user on the machine was affected by the problem.

Since the issue occured on every platform for every user, inside vagrant-VMs and even on different machines (Laptop, Desktop-PC, …) it was soon clear that the solution probably had nothing to do with npm.

After weeks of troubleshooting without any result I realized that the problem only ocurred when running the command at home. The command executed fine when my Laptop was inside other networks. This led me to the conclusion that the network configuration was the cause of all problems. Since all machines received their settings via DHCP my first try was to manually define the DNS settings.

Et voilà: Everything worked as expected.

Solution

Change the DNS servers you use. You’re probably using the default servers provided by your ISP. There are plenty of other public DNS servers out there. For a quick test you might even use the ones operated by Google: 8.8.8.8 and 8.8.4.4 .

Posted in Debian, Node.js, Ubuntu, Vagrant | Comments Off

Simulate the environment of Cron Jobs

by Lorenz Bausch Posted on March 21, 2016

Often you will find yourself in the situation that one of your cron jobs works perfectly if you execute it manually but fails as soon as is gets executed by cron. The root cause might be the different environment. To simulate the environment of a cron job add the following entry to your crontab using crontab -e:

* * * * * env > /root/cronenv

1	* * * * * env > /root/cronenv

This will create the file cronenv in your root directory and dump all available environment variables into it. Once the file was created remove the entry from your crontab and take a look at its contents:

HOME=/root
LOGNAME=root
PATH=/usr/bin:/bin
LANG=en_US.UTF-8
SHELL=/bin/sh
PWD=/root

HOME=/root

LOGNAME=root

PATH=/usr/bin:/bin

LANG=en_US.UTF-8

SHELL=/bin/sh

PWD=/root

This pretty much sums up the environment. To enter this environment use the following command:

env - `cat /root/cronenv` /bin/sh

1	env - `cat /root/cronenv` /bin/sh

Now you can execute your cron job command, see what happens and fix your error. Once you’re done simply type exit to leave the environment.

See this Stack Overflow answer for more information.