After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
Some github actions that use `bash` expect interactive features to be available. One such action is the [use-nix-shell](https://github.com/rrbutani/use-nix-shell-action) action. I couldn't find a way to override this even with `cfg.extraPackages`, due to the way the path is ordered.
Since the buildbot package can be overwritten, it can be build against a
different python version.
This pull request makes sure we don't use the wrong python version.
This makes using buildbot-nix easier for both nixpkgs unstable and
nixpkgs stable.
Shellcheck complains:
> args=(
> ^-- SC2054 (warning): Use spaces, not commas, to separate array elements.
Add a comment disabling shellcheck in this case and annotating why.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
An ancient comment says to unset this variable after 16.03. Considering
we've just gotten past 24.05, I think it's safe to remove this finally.
Tests still pass after this change.
* buildkite-agent: 3.59.0 -> 3.76.1
* nixos/buildkite-agent: put each agent in its own private /tmp
Workaround for https://github.com/buildkite/agent/issues/2916, but
probably still a good idea.
I guess my time has come as well...
With this commit, I'm not just dropping my maintainer entry, but I'm also
resigning from my duties as a board observer and NixCon project lead.
I also terminated my Summer of Nix contract today.
I'll also stop hosting the local NixOS meetup.
The only "project" I'll finish under the NixOS Foundation umbrella is
Google Summer of Code because the mentees aren't even remotely
responsible for why I'm leaving, and it would be unfair to leave them
hanging.
I'm grateful for all the things I was able to learn, for all the experiences
I could gather, and for all the friends I made along the way.
NixOS is what makes computers bearable for me, so I'll go and work on
some fork (*something something* you always meet twice in life).
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
