gitlab-runner register appears to confuse tokens
Summary
There are two kinds of tokens:
- one needed to register a new runner, passed to the
-t
or--token
option (or set via theCI_SERVER_TOKEN
environment variable) - one used by an already registered runner, passed to the
-r
or--registration-token
option (or set via theREGISTRATION_TOKEN
environment variable)
When trying to register a new runner when CI_SERVER_TOKEN
is set, I keep seeing
WARNING: If you want to register use the '-r' instead of '-t'.
before the registration procedure PANIC
s. If I understand correctly, new runners use the CI_SERVER_TOKEN
to register themselves. The REGISTRATION_TOKEN
is obtained during this process somewhere and used during later communication wit the GitLab instance to which the runner registered itself.
Unsetting the environment variable and entering its value manually works around the problem.
Background
I am trying to set up shared runners with a docker-compose.yml
file to automatically register themselves to a GitLab instance. That in itself is a somewhat awkward endeavor (I'm using a "here" document to work around the interactivity requirement because the REGISTER_NON_INTERACTIVE
environment variable or -n
or --non-interactive
options didn't seem to work for me although that may have been caused by the behavior in this issue) but can be accomplished by hacking up the /entrypoint
.
Steps to reproduce
-
Run
docker run -it --rm --entrypoint /bin/bash gitlab/gitlab-runner:alpine-v10.8.0
-
Inside the container:
- set
CI_SERVER_URL
to point to a functional GitLab instance - set
CI_SERVER_TOKEN
to a valid registration token for that GitLab instance
- set
-
Run
gitlab-runner register
-
Hit enter to accept the "GitLab coordinator" URL
-
Watch it spew
Token specified trying to verify runner...
WARNING: If you want to register use the '-r' instead of '-t'.
ERROR: Verifying runner... is removed runner=********
PANIC: Failed to verify this runner. Perhaps you are having network problems
where the `runner` value matches the start of the `CI_SERVER_TOKEN`.
Unsetting the `CI_SERVER_TOKEN` and entering it manually works around this. That is, the problem is *not* caused by network problems.
## Actual behavior
See above.
## Expected behavior
`gitlab-runner` uses the `CI_SERVER_TOKEN` to register a *new* runner.
## Relevant logs and/or screenshots
See above.
## Environment description
This is a custom installation using the [`sameersbn/docker-gitlab`](https://github.com/sameersbn/docker-gitlab) image (at version 10.8.3). The `gitlab` service as well as `postgres`, `redis` and `runner` are all in the same `docker-compose.yml` file. The `docker` engine is at `18.05.0-ce` and runs in Swarm mode.
### Used GitLab Runner version
```console
# gitlab-runner --version
Version: 10.8.0
Git revision: 079aad9e
Git branch:
GO version: go1.8.7
Built: 2018-05-22T03:24:56+00:00
OS/Arch: linux/amd64