You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: add option to use a pre-registered Runner (#1115)
## Description
GitLab announced then [Next GitLab Runner Token
Architecture](https://docs.gitlab.com/ee/architecture/blueprints/runner_tokens/index.html#proposal).
Runners have to be registered manually.
This PR adds a new import parameter
`runner_gitlab.preregistered_runner_token_ssm_parameter_name` holding
the name of a SSM parameter (type: `SecuredString`). This parameter
contains the GitLab Runner token obtained from GitLab. All other
registration methods will still work, but have been marked as deprecated
and will be removed with
[v8.0.0](https://github.com/cattle-ops/terraform-aws-gitlab-runner/milestone/4)
end of the year.
This also solves the problems with Runners removed from GitLab at
shutdown, resulting in new Runners not able to start.
Closes#1074 and #1109
## Verification
- [x] deployed the module using the new registration version. Runner is
online.
- [x] deployed the module using the old authentication schema. Runner is
online.
The base image used to host the GitLab Runner agent is the latest available Amazon Linux 2 HVM EBS AMI. In previous versions of
18
18
this module a hard coded list of AMIs per region was provided. This list has been replaced by a search filter to find the latest
19
19
AMI. Setting the filter to `amzn2-ami-hvm-2.0.20200207.1-x86_64-ebs` will allow you to version lock the target AMI if needed.
20
20
21
-
> 💥 **If you are using GitLab >= 16.0.0**: `registration_token` will be deprecated!
22
-
23
-
>GitLab >= 16.0.0 has removed the `registration_token` since they are working on a [new token architecture](https://docs.gitlab.com/ee/architecture/blueprints/runner_tokens/). This module handle these changes, you need to provide a personal access token with `api` scope for the runner to authenticate itself.
24
-
25
-
>The workflow is as follows ([migration steps](https://github.com/cattle-ops/terraform-aws-gitlab-runner/pull/876)):
26
-
>1. The runner make an API call (with the access token) to create a new runner on GitLab depending on its type (`instance`, `group` or `project`).
27
-
>2. GitLab answers with a token prefixed by `glrt-` and we put it in SSM.
28
-
>3. The runner will get the config from `/etc/gitlab-runner/config.toml` and will listen for new jobs from your GitLab instance.
21
+
The Runner uses a token to register with GitLab. This token is stored in the AWS SSM parameter store. The token has to be created
22
+
manually in GitLab and stored in the SSM parameter store. All other registration methods are deprecated and will be removed in
23
+
v8.0.0.
29
24
30
25
## Install the module
31
26
@@ -45,40 +40,7 @@ terraform destroy
45
40
46
41
## Scenarios
47
42
48
-
### Scenario: Basic usage on GitLab **< 16.0.0**
49
-
50
-
Below is a basic examples of usages of the module. Regarding the dependencies such as a VPC, have a look at the [default example](https://github.com/cattle-ops/terraform-aws-gitlab-runner/tree/main/examples/runner-default).
0 commit comments