Runner ignores config file.

Hi,

I'm trying to register runner with config file but it's seems to be ignored, I get FATAL ERROR: The 'url' needs to be entered but it is in config. config.toml:

concurrent = 1

[[runners]]
  name = "foo"
  url = "http://<url>"
  token = "token"
  executor = "shell"
  limit = 1
  builds_dir = ""
  shell = "bash"

I've tried with example config from https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/config.toml.example and errors still appears.

How did you install it? How do you run it? How do you register?

By debian repository, gitlab_ci_multi_runner register -n -c config.toml.

Added ~58729 label

It's seems that -c option to register command specify only output config file, is there any way to register runner based on existing config? When I'm trying to run with custom config (without register) no runners are working.

Config contains list of registered runners. It's not designed to create config yourself and feed the register command.

Why not? It would be convenient to use it with e.g. Puppet (my case). This way I could only specify CI token in my manifests and have all runners automatically provisioned.

You can do most of the configuration with: gitlab-ci-multi-runner register, please check: gitlab-ci-multi-runner register --help

@ayufan, I'd say that really not a good design because:

1. not every parameters available in toml config can be passed via gitlab-ci-multi-runner register. This bothers me very much because that follows it takes some additional work to implement fully automatic, self-registering slaves. It's still possible, but just not straight and forward enough. People have to run gitlab-ci-multi-runner run as a background daemon and run gitlab-ci-multi-runner register multiple times after that being run. Inside a docker, that means when you're going to run an image as daemon, you have to:

gitlab-ci-multi-runner run ... & # Must be running in the background
gitlab-ci-multi-runner register ...
while [ true ]; do sleep 1000000; done

It's just ugly.

2. most parameters required for runner registration are already available in a toml config. Why bother having yet another place keeping registration information?

GitLab & GitLab CI is really a great service, but it definitely can do better.

@vicamo

Can you describe the case why you want to have full automatic self-registering slaves? This is something that I strongly discourage to use for multiple reasons where one of them is expose of runner token.

I guess I need more information about your workflow to think about the way to extend the register command.

mentioned in issue #92 (closed)

Milestone changed to v0.6.0

is it possible to define environmens using gitlab-ci-multi-runner register, that will be used in mysql container setup, such MYSQL_ALLOW_EMPTY_PASSWORD, MYSQL_USER or MYSQL_PASSWORD?

@umatomba Not yet register. You can add that to config.toml: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md#the-runners-section

@ayufan I had a project that packages Debian deb for multiple architectures. Preparing these environments could be lengthy and error prone, therefore I've made them available as docker images, so people may run any of them to begin the devel. Then I want it be easy to setup gitlab-ci runner for their own fork before sending a merge request. The ideal case is to run one docker image and all the supported runners one for each supported arch are setup automatically. This follows I have to run gitlab-ci-multi-runner register multiple times to generate a correct config.toml. It is fine in the first place because there is a --non-interactive option and I can work around this with a run-parts ... as done here and here. However, just not all options are supported through gitlab-ci-multi-runner register command line interface, which follows I have to MANUALLY edit that config, save it and then gitlab-ci-multi-runner reloads. No, I cannot simply overwrite it because there is a run time generated runner token for each runner instance written to that file (or yes, just need some more terrible parsing, rewrite, etc.). In the end, either I cannot specify some advance options to do fine tunes, or I have to sacrifice the convenience part and ask for additional steps to take. I now take the first option and I don't like that.

So what should really have been done here? A few possible solutions for me:

1. separate run time state information from static configurations. As I mentioned in https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/92#note_1644164 , although you denied, config.toml contains lines from 1) arguments for gitlab-ci-multi-runner register, 2) run time generated runner toke from server, 3) additional directives from manual editing. If the runner tokens are not stored in the same file, I can simply save this config at the first time, call gitlab-ci-multi-runner register to get runner tokens, overwrite this config directly, and every thing done.
2. Allow gitlab-ci-multi-runner register to take config.toml as input file as suggested in this issue. With this, I may simply prepare an initial config.toml and call gitlab-ci-multi-runner register multiple times to let it write runner tokens inside. I still don't like the thing that you write something new into the config I provided, but it's probably acceptable because I can still move that file into /var/lib/gitlab-ci myself and specify the new path for the service.

@vicamo I'll look for simple way to expose all config options for register command. I agree that this is bad requirement to change config.toml if you want to modify not-exposed options.

The important thing that it was never intended to re-register GitLab Runner every container start. This doesn't make much sense. The main idea is to do it once and use it as long as runner configuration matches your build environment.

@vicamo The register command accepts all parameters that are present in config.toml.

Status changed to closed