Release 0.5.0

The upcoming release contains number of security features and bug fixes:

The 0.5.0 simplifies installation procedure and makes the runner more secure: by protecting runner's config and not requiring the docker group ownership in order to use built-in docker executor. The runner contains alias gitlab-runner and replaces old omnibus-gitlab-runner. For new installations the gitlab-runner user is created instead of gitlab_ci_multi_runner.

The upcoming version is available as Bleeding Edge: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/bleeding-edge.md

The documentation doesn't yet reflect recent changes.

I'll be happy if you could test and post review if it doesn't break existing setups.

TL;DR

1. The runner service when installed from deb/rpm is run by root. The service stores config in /etc/gitlab-runner/config.toml which is owned by root and has permission 0600.
2. The deb/rpm installer creates gitlab-runner user or uses gitlab_ci_multi_runner if found (backward compatibility).
3. The deb/rpm installer imports ~gitlab_ci_multi_runner/config.toml.
4. The deb/rpm installer includes gitlab-runner alias for gitlab-ci-multi-runner.
5. The runner run command accepts --user that is used to specify the user for executing shell scripts. The shell scripts are run with su --shell /bin/bash --login
6. The gitlab-ci-multi-runner install/uninstall/start/stop/restart works only for root on Linux.
7. When gitlab-ci-multi-runner register/run/verify is executed by normal user (non-root) the configuration is stored in $HOME/.gitlab-runner/config.toml: this changes behaviour for linux and darwin, previously the config was stored in current directory.
8. The repository contains alpine-based runner image with minimal footprint.
9. The runner contains tests that allows to verify installation and upgrade on: centos:6/7, debian:wheezy/jessie, ubuntu:precise/trusty/utopic
10. The runner includes support for upcoming docker CI features
11. Colorised build log.

/cc @jacobvosmaer @sytses

Nice list, some thoughts:

• Call the user gitlab-runner? I don't understand what the underscore is for
• The default behavior for the shell executor should be to drop privileges to gitlab_runner, right? This is not clear to me from the list.

Call the user gitlab-runner? I don't understand what the underscore is for

Can you point to omnibus-gitlab-runner package? I will check what user is created there.

The default behavior for the shell executor should be to drop privileges to gitlab_runner, right? This is not clear to me from the list.

Yes. The privileges are dropped by su. It's done by executing shell scripts with: su --shell /bin/bash --login gitlab_runner.

/cc @jacobvosmaer

Can you point to omnibus-gitlab-runner package? I will check what user is created there.

@jacobvosmaer No need for that. The omnibus installation advises to create gitlab-runner. I'll change that.

Ok. Great. So basically what we miss is testing.

About that /etc/gitlab-runner/config.toml, it should really be /var/lib/gitlab-runner/config.toml or simply /run/gitlab-runner/config.toml. According to FHS, /etc is for static configuration files, and in some cases it's even read-only. Since config.toml is re-generated every time a new runner is registered/unregistered, it's more like a program execution state file, and that, according to FHS again, /var/lib is its better home. However, /var/lib is for keeping information across system reboots and process restarts, but config.toml becomes invalid because of #90, /run fits all the conditions well as stated in FHS.

Once #90 is recognized a must-fix issue and gitlab-ci-multi-runner does reload this file while starting up, that makes it really a static configuration file and it would be more reasonable to keep it in /etc. Per runner token information should still be saved in /var/lib or /run though.

@vicamo

The config.toml is never changed by the runner service, so basically this configuration is static and not dynamic.

1. Putting the configuration into /run would assume that this configuration is somehow generated dynamically which is not true.
2. Putting the configuration into /var/lib would make assumption that the service changes the configuration which is also not true.
3. The only situation when the configuration changes is by user intervention or by executing register, unregister or verify command.
4. The runner service only reads the config, so /etc if needed can be mounted as read-only.
5. Config is valid between system reboots. The problem you are mentioning is different and most likely because of non-standard usage of gitlab-runner.

The #90 (closed) should be resolved and I'm open to possible solutions.

Reassigned to @ayufan

Status changed to closed