Packages built with `haskellPackages.callHackage` won't be rebuilt when
updating `all-cabal-hashes`.
The removed comment was keeping a reference to the `cabal2nix` call,
which itself depends on `all-cabal-hashes`, in order to keep this file
during a garbage collection.
The tradeoff is between:
- The current behavior: a mass rebuild, any change of `all-cabal-hashes`
triggers a rebuild of all the packages built with `callHackage` and
packages which depend on them. This can take hours, and may happen
after a "small" unrelated change (i.e. an user is bumping
`all-cabal-hashes` in order to use a new package from hackage). It
also have global impacts in a project (long rebuild in CI, new entries
in cache, developers need to fetch the new entries, ...). In this
context, `cabal2nix` entries are not garbage collected.
- The new behavior: No mass rebuild, but `cabal2nix` derivations need to
be recomputed after a garbage collection. This is usually fast (a few
seconds by call), linear with the number of calls and should not
happen a lot (i.e. users are not garbage collecting everyday).
See https://github.com/NixOS/nixpkgs/issues/194751 for details.
We don't need both wget and curl, so let's use only curl (which is
part of a minimal NixOS closure, unlike wget).
Logging to the console is helpful for debugging.
Instances without SSH keys configured will receive a 404 from the
metadata server when attempting to fetch an SSH key. This is not an
actual problem though, and shouldn't result in the service failing.
If the metadata server cannot be reached, the script will fail at an
earlier stage when attempting to get authentication data.
This also removes automatic enablement/mounting of instance store swap
devices and ext3 filesystems. This behaviour is strongly opinionated
and shouldn't be enabled by default.
The unionfs behaviour never took effect anyway, because the AMI
manifest path only exists for instance store-backed AMIs, which have
not been supported by nixpkgs since
84742e2293 (2019).
The tests TLS setup was bogus: the xmpp-send-message script was trying
to connect to the server through a bogus domain name. Injecting the
right one.
I'm a bit confused about that one. I know for sure this NixOS test
succeeded last time I checked it, but the TLS conf is bogus for sure.
I assume the slixmpp SNI validation was a bit too loose and was
tightened at some point.
The xmpp-sendmessage the slixmpp-powered python script tend to timeout
and block the nixos channels.
Adding a signal-based timeout making sure that whatever happens, the
script won't run for more than 2 minutes. That should be pleinty
enough time to finish regardless of the runner specs. As a data point,
it runs in about 10 secs on my desktop machine.
The change that allows setting the secrets by an environment file had
the undocumented side effect of allowing to set any key by the environment
file (Related PR: https://github.com/tulir/mautrix-telegram/pull/332).
This is required to e.g. set `bridge.login_shared_secret`, which was not
documented before.
GitHub: closes#103347
Closes#198646
* The options `password`/`basicAuthPassword` were removed for
datasources in Grafana 9. The only option to declare them now is to use
`secureJsonData`.
* Fix description for contactPoints provisioning: when using file/env
providers, nothing will be leaked into the store.
* Fix regex in file-provider usage check: it's also possible to either
use `$__env{FOO}` or `$FOO` to fetch secrets from the environment.
* Fix warning for datasources: `password`/`basicAuthPassword` was
removed, also check for each setting in `secureJsonData` if
env/file-provider was used (then no warning is needed!).
The hack with `either` had the side-effect that the sub-options of the
submodule didn't appear in the manual. I decided to remove this because
the "migration" isn't that hard, you just need to fix some module
declarations.
However, `mkRenamedOptionModule` wouldn't work here because it'd create
a "virtual" option for the deprecated path (i.e.
`services.grafana.provision.{datasources,dashboards}`), but that's the
already a new option, i.e. the submodule for the new stuff.
To make sure that you still get errors, I implemented a small hack using
`coercedTo` which throws an error if a list is specified (as it would be
done on 22.05) which explains what to do instead to make the migration
easier.
Also, I linkified the options in the manual now to make it easier to
navigate between those.
