The key change here is, that the match was on the hydra database only
previously, but is now limited to to the hydra role instead. This avoids
conflicts with rules that are created by other modules or downstream
users.
With this change, we can remove the additional "postgres postgres" line,
because the default pg_hba line will kick in again and allow the
postgres user access to the postgres role.
Renaming the map from hydra-users to hydra is for consistency, so that
all modules can define maps matching in name with the role they manage.
The change from ident to peer is just cosmetic, ident is only used for
TCP connections and falls back to peer anyway.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Previously some modules used `config.environment.etc."ssl/certs/ca-certificates.crt".source`, some used `"/etc/ssl/certs/ca-certificates.crt"`, and some used `"${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"`. These were all bad in one way or another:
- `config.environment.etc."ssl/certs/ca-certificates.crt".source` relies on `source` being set; if `text` is set instead this breaks, introducing a weird undocumented requirement
- `"/etc/ssl/certs/ca-certificates.crt"` is probably okay but very un-nix. It's a magic string, and the path doesn't change when the file changes (and so you can't trigger service reloads, for example, when the contents change in a new system activation)
- `"${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"` silently doesn't include the options from `security.pki`
Co-authored-by: Shelvacu <git@shelvacu.com>
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
