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
My reasons following Mint are:
1. Geary signed https://stopthemingmy.app, per request we shouldn't pre-ship it under a themed desktop environment.
See also b7937b4509
2. Hexchat is still gtk2 and is not maintained anymore, Mint encourages switching to Matrix instead.
See also https://blog.linuxmint.com/?p=4675 ("Joining the Matrix")
The spook package includes two separate integrations and the module was
adapted to account for that scenario. Add a test to ensure the changed
keeps working correctly going forward.
frenck/spook includes a second manifest for an integration. The current
copyCustomComponents script assumed that only one component directory
will be found, which in this case resulted in a malformed symlink
destination:
lrwxrwxrwx 1 hass hass 224 Jun 23 17:23 spook -> '/nix/store/r41ics22zs578avzqf7x86plcgn2q71h-python3.12-frenck-spook-v3.0.1/custom_components/spook/integrations/spook_inverse'$'\n''/nix/store/r41ics22zs578avzqf7x86plcgn2q71h-python3.12-frenck-spook-v3.0.1/custom_components/spook'
Since stalwart-mail 0.6.0, queue and report files are located in
the shared `storage.{data,blob}` stores. The `{queue,report}.path`
settings no longer had any effect since then.
I'm also removing the creation of the associated extra directories
in the `preStart` script. This should not cause any issue with old
setups since 0.6.0 was already packaged when 24.05 was released.
