New registration flow

[juokelis]

Pull Request (PR) description

New registration flow

This Pull Request (PR) fixes the following issues

Fixes #186

[juokelis]

I'm not very good with tests, but I imagine, that automated testing is complicated now when there's a new runner activation flow. There's no more getting an authentication token from GitLab through API. You create a runner from GitLab UI, get an authentication token there, and use it to configure your runner.

[baurmatt]

tbh, I'm not sure if it's worth to keep all that Ruby code magic just to verify the runner. It could also just be an exec calling gitlab-runner verify:

root@newworld:~# docker exec -it gitlab-runner gitlab-runner verify
Runtime platform                                    arch=amd64 os=linux pid=80 revision=6428c288 version=17.2.0
Running in system-mode.

Verifying runner... is alive                        runner=8s7eCp3D
ERROR: Verifying runner... is removed               runner=8s7eCp3D status=POST https://gitlab.example.org/api/v4/runners/verify: 403 Forbidden
FATAL: Failed to verify runners
root@newworld:~# echo $?
1

Edit: There is just no need for all the Deferred and Ruby logic, just to verify if the runner token is valid. With the new registration logic, we could switch to a simple static template file and be good.

[juokelis]

tbh, I'm not sure if it's worth to keep all that Ruby code magic just to verify the runner. It could also just be an exec calling gitlab-runner verify:

root@newworld:~# docker exec -it gitlab-runner gitlab-runner verify
Runtime platform                                    arch=amd64 os=linux pid=80 revision=6428c288 version=17.2.0
Running in system-mode.

Verifying runner... is alive                        runner=8s7eCp3D
ERROR: Verifying runner... is removed               runner=8s7eCp3D status=POST https://gitlab.example.org/api/v4/runners/verify: 403 Forbidden
FATAL: Failed to verify runners
root@newworld:~# echo $?
1

Edit: There is just no need for all the Deferred and Ruby logic, just to verify if the runner token is valid. With the new registration logic, we could switch to a simple static template file and be good.

Technically most likely yes, we could get there in the end. My ain was not to ruin current process and leave the module backwards compatible with older runner (like 15.2 on Debian 9). Of course module states to support 11-12 though 🗡️ Anyway next version could be much simpler, by removing all that magic, yes :)

[bastelfreak]

leave the module backwards compatible with older runner (like 15.2 on Debian 9)

We really don't need to support Debian 9. Debian 11 and 12 are fine.

[fidalcastro]

@juokelis I tried out your PR code in my test environment but I am getting following error. It looks weird, I ensured verify method is available in lib/puppet_x/gitlab/runner.rb

Only changes I've made to my hiera is replacing the registration-token key with token & added the token value generated from the Gitlab UI by following new registration method which of course prefixed with glrt-

Error: /Stage[main]/Gitlab_ci_runner::Config/Concat[/etc/gitlab-runner/config.toml]/Concat_file[/etc/gitlab-runner/config.toml]: Failed to generate additional resources using 'eval_generate': undefined method `verify' for PuppetX::Gitlab::Runner:Module
Error: Failed to apply catalog: undefined method `verify' for PuppetX::Gitlab::Runner:Module

Any idea ?