In rare cases, the nixpkgs stable version of a package can be newer
than in unstable nixpkgs. [1]
When this happens, choose the newer stable version instead of the
older unstable version.
[1] E.g., when a package is updated in both nixpkgs stable and unstable,
and nixpkgs stable is released before unstable.
This makes scripts fail early on request errors.
Previously, curl exited with status 0 when enountering HTTP error status
codes.
`-fsS` equals `--fail --silent --show-error`.
This fixes a bug where the version update message for v0.0.65 is erroneously triggered
because the krops config is not included when evaluating secrets.
This checks that creating module docs for search.nixos.org succceeds.
Errors can happen when complex `default` values can't be evaluated
or on malformed Docbook XML in descriptions.
The `nix` command is an experimental feature and should be avoided in
user-facing code.
I recently saw `nix eval` failing for a user who was asking for help
via Matrix.
- import pkgs without the global config to avoid pulling in external state
- rename `path` -> `setPath`
- export `nixpkgsUnstable`
This avoids garbage collection of nixpkgs-unstable for gcrooted
shell environments (like those created by lorri)
- The message is now a nix string, which simplifies formatting.
- The message can be now be modified via overrideAttrs in client shells.
This is more effective than changing the message in Bash.
- Don't overwrite `nix-bitcoin-release.nix` on errors
- Show a message to indicate whether `nix-bitcoin-release.nix` was
updated
- Don't start a shell when called noninteractively
Also, update `usage.md` and reformat `shell.nix`.
Previously, when used to update `nix-bitcoin-release`, the error
wasn't displayed but instead written to `nix-bitcoin-release`.
Also, show curl error messages.
`generate-secrets` is no longer a monolithic script. Instead, it's
composed of the values of option `nix-bitcoin.generateSecretsCmds`.
This has the following advantages:
- generate-secrets is now extensible by users
- Only secrets of enabled services are generated
- RPC IPs in the `lnd` and `loop` certs are no longer hardcoded.
Secrets are no longer automatically generated when entering nix-shell.
Instead, they are generated before deployment (via `krops-deploy`)
because secrets generation is now dependant on the node configuration.
The user's local node configuration directory usually contains a copy of
examples/shell.nix.
1. Move the shell implementation from shell.nix to nix-bitcoin/helper/makeShell.nix
Because the shell is no longer defined locally in the user's config
directory, we can now ship new shell features via nix-bitcoin updates.
2. Simplify examples/nix-bitcoin-release.nix
nix-bitcoin-release.nix, as generated via `fetch-release`, now
contains a simple fetchTarball statement which can be directly imported.
This allows us to get rid of the extra `nix-bitcoin-unpacked` derivation
which adds a dependency on the user's local nixpkgs.
To keep `fetch-release` as simple as possible for easy auditing, we just
fetch and verify a `nar-hash.txt` file that is now uploaded
via `push-release.sh`.
A migration guide for updating the user's local `shell.nix` is
automatically printed when the user starts a new shell after updating
nix-bitcoin.
This is achieved by throwing an error in `generate-secrets`, which is called
on shell startup.
This commit is required to deploy the new extensible `generate-secrets`
mechanism introduced in the next commit.
This script is potentially fetched from an untrusted source and should
be in good shape to be easily auditable.
- Create just one TMPDIR
- Improve comments
- Use `cut` to extract sha256
- Use camelCase var names like in other scripts
- Make more economic use of the free CI resources by removing redundant build tasks:
- Build unstable pkgs in a single separate task ("pkgs_unstable").
- All stable pkgs are implicitly built by the modules tests.
- The build script (ci/build.sh) can now be executed locally for easier
debugging.
- Use an explicit 'cachix push' command instead of helper/wait-for-network-idle.rb.
This is simpler and more reliable.
The subkey used for signing releases recently expired (which is ignored when
verifying with gpg). The primary key would expire soon. Therefore this commit
adds a key with extended expiry date of both primary key and subkey.
This further speeds up builds, in particular the modules test in the
next commit. By checking if the expected final build output has already
been cached, we can even skip the download of cached builds.
