nixos/gitlab-runner: Add support runner authentication tokens

Support for *runner registration tokens* is deprecated since GitLab
16.0, has been disabled by default in GitLab 17.0 and will be removed in
GitLab 18.0, as outlined in the [GitLab documentation].

It is possible to [re-enable support for runner registration tokens]
until GitLab 18.0, to prevent the registration workflow from
breaking.

*Runner authentication tokens*, the replacement for registration tokens,
have been available since GitLab 16.0 and are expected to be defined in
the `CI_SERVER_TOKEN` environment variable, instead of the previous
`REGISTRATION_TOKEN` variable.

This commit adds a new option
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`.
Defining such option next to
`services.gitlab-runner.services.<name>.registrationConfigFile` brings
the following benefits:
- A warning message can be emitted to notify module users about the
  upcoming breaking change with GitLab 17.0, where *runner registration
  tokens* will be disabled by default, potentially disrupting
  operations.
- Some configuration options are no longer supported with *runner
  authentication tokens* since they will be defined when creating a new
  token in the GitLab UI instead. New warning messages can be emitted to
  notify users to remove the affected options from their configuration.
- Once support for *registration tokens* has been removed in GitLab 18,
  we can remove
  `services.gitlab-runner.services.<name>.registrationConfigFile` as
  well and make module users configure an *authentication token*
  instead.

This commit changes the option type of
`services.gitlab-runner.services.<name>.registrationConfigFile` to
`with lib.types; nullOr str` to allow configuring an authentication
token in
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`
instead.

A new assertion will make sure that
`services.gitlab-runner.services.<name>.registrationConfigFile` and
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`
are mutually exclusive. Setting both at the same time would not make
much sense in this case.

[GitLab documentation]: https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#estimated-time-frame-for-planned-changes
[re-enable support for runner registration tokens]: https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#prevent-your-runner-registration-workflow-from-breaking

0 files changed, 0 insertions, 0 deletions