| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
[#210] Add activation script for darwin system and provide a usage example
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: It's possible to use 'deploy-rs' for deploying 'darwinSystem'
configuration from 'nix-darwin' to a darwin system. However, there is no
dedicated activatiot script for darwin and thus one has to come up with
'custom' activation script.
Solution:
1) Add 'darwin' attribute to 'lib.activate' that provides a script that
should be used to activate 'darwinSystem' config with 'deploy-rs'.
2) Add a new 'examples/darwin' example that provides simple flake for
deploying configuration to a darwin target.
|
|/
|
|
|
|
|
|
|
| |
Use the deploy-rs from the final packages set. This can avoid rebuilding
deploy-rs when using it in a nixos config. It can use the version cached
in nixpkgs.
Also add instructions to the readme on how to craft an overlay that uses
nixpkgs deploy-rs.
|
|\
| |
| | |
Add new activation strategy `boot` as equivalent to `nixos-rebuild boot`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This can be useful when e.g. deploying a kernel update to a target host.
You usually plan a reboot (or kexec) after that to activate the new
kernel. However you don't want to wait for services to be restarted
first since these will be "restarted" anyways on the reboot. In cases
like GitLab or the Atlassian stack this actually makes a difference.
This patch changes the following things:
* If `--boot` is provided, `nix-env -p profile-to-activate --set` is
called for each deployed profile to make sure that it is activated
automatically after a reboot.
* However, the actual activation (e.g. `switch-to-configuration switch`)
is skipped. Instead:
* For NixOS, `switch-to-configuration boot` is called to set the new
profile as default in the bootloader.
* For everything else, nothing else is done. The profile is already
the new default (and thus picked up on the next boot).
|
|/
|
|
| |
Closes #162
|
|
|
|
|
|
|
| |
The top-level `system` attribute has been deprecated for quite a
while. See
https://github.com/NixOS/nixpkgs/commit/4246d6ce21d2d8d33e2d30f42b3d9d446c5dc143
|
|
|
|
|
|
|
| |
The `runCommand` function has been using `stdenvNoCC` for quite a
while and `runCommandNoCC` is correspondingly deprecated. See
https://github.com/NixOS/nixpkgs/commit/9feb144c8cc4f4b71a9c23b2f7fd6b2ea55649e5
|
|
|
|
|
|
|
|
|
| |
nix 2.7 renamed defaultApp and defaultPackage. Both the
old and new names are supported in 2.7, but 2.8 has removed
support for the old names, breaking the nix run invocation.
Old names are kept in this PR to keep compatibility with nix 2.6,
but could be removed if support of this version is not needed anymore.
|
|
|
|
|
|
|
| |
Frameworks are libraries used at runtime, so should be in buildInputs
and not nativeBuildInputs.
Closes https://github.com/serokell/deploy-rs/issues/132
|
| |
|
| |
|
| |
|
|\
| |
| | |
fix: add meta.description
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
| |
In 5d5da48 (https://github.com/serokell/deploy-rs/pull/81), $DRY_ACTIVATE
is used in a bash script with -u. When DRY_ACTIVATE is not set (which it
is not for older profiles), the script fails. Fix this by setting a fallback.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Now that activate uses a cross-platform fs notification library, we
can build it on Darwin again (and build its deps separately, speeding
up recompiles there).
|
| |
|
| |
|
|
|
|
|
| |
This should point to the correct path if the target platform differs
fro the deploying platform.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add xcbuild as native build input 2 ways & pass --verbose to cargo build
* Make "deploy" build on macOS
* Bump the nixpkgs version to one that ships Rust 1.47, which can
produce binaries under macOS 11 (Big Sur).
* Use darwin-specific options that let Naersk build the "deploy"
binary under macOS. (With a work-around for
https://github.com/nmattia/naersk/issues/127, which prevents this
from being much more straight-forward).
Unfortunately, the "activate" binary can't be built under macOS due to
the inotify dependency; that means the best we can do is to run the
deploy under macOS, not deploy *to* macOS.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
jsonSchema check in flake lib
|
| |
|
| |
|