| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
serokell/rvem/#245-return-non-zero-exit-code-for-confirmation-timeout
[#245] Return non-zero exit code in case of confirmation timeout
|
|/
|
|
|
|
|
|
|
|
|
| |
Problem: When profile activation confirmation fails due to
confirmation timeout and performs a rollback, zero exit code is
returned. Such a behavior is confusing since rollback usually means
something went wrong during deployment and it shouldn't return
successful exit code.
Solution: Explicitly return confirmation waiting error instead of
printing it and silently signalizing success.
|
|\
| |
| |
| |
| | |
serokell/rvem/make-wait-activation-timeout-configurable
[Chore] Make activation wait timeout configurable
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Currently profile activation waiting timeout is hardcoded to
240 seconds, see https://github.com/serokell/deploy-rs/pull/48.
In some cases, this timeout can be exceeded (e.g.
activation performs a heavy DB migration and waits for it to finish
before considering the profile activation succesful).
Solution: Make this timeout configurable via 'activationTimeout' deploy
attribute or corresponding '--activation-timeout' CLI option. For the
sake of backward compatibility, the new 'wait' subcommand
'--activation-timeout' option is made optional and defaults to 240
seconds if it wasn't provided.
|
|\
| |
| | |
[Chore] fix error messages claiming to have rolled back when not actually doing so
|
|/
|
|
|
|
| |
doing so
closes: #241
|
|\
| |
| | |
[Chore] Run CI checks on 'pull_request'
|
|/
|
|
|
|
|
|
| |
Problem: We want to be able to run CI checks on PRs from external forks.
However, this is only possible with 'on: pull_request', while currently
CI is triggered 'on: push'
Solution: Change CI triggering condition to 'on: pull_request'.
|
|\
| |
| | |
Replace jsonschema-cli with check-jsonschema
|
|/
|
|
|
| |
jsonschema-cli is deprecated and will be removed in the future.
The recommended replacement is check-jsonschema.
|
|\
| |
| | |
[#201] Deduce profile directory during activation
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Since https://github.com/NixOS/nix/pull/5226 nix profiles for
users are stored in 'XDG_STATE_HOME' or 'HOME' directory. However,
'deploy-rs' still expects profiles to be present in
'/nix/var/nix/profiles/per-user'. As a result, an attempt to deploy a
profile with newer nix may fail with an error about non-existing files.
Solution: Instead of deducing the profile path prior to ssh'ing and
actual activation, deduce the path to the profile during as a part of
'activate-rs' invocation.
Now if the profile path is not specified explicitly as an attribute in
profile within the deploy flake, the path to the profile is determined
based on the user to which the profile belongs and on the values of
'XDG_STATE_HOME' and 'HOME' variables.
Additionally, if the old profile directory (in
'/nix/var/nix/profiles/per-user') for a given user already exists, it is
used instead for the sake of backward compatibility.
|
|/
|
| |
Replace "eachother" with "each other".
|
|\
| |
| | |
actually merge confirm_timeout into merged_settings
|
|/ |
|
|\
| |
| | |
[#210] Add activation script for darwin system and provide a usage example
|
| |
| |
| |
| | |
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.
|
|\ \
| |/
|/| |
Make it possible to not rebuild deploy-rs
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | |
| | |
| | | |
serokell/rvem/#202-add-workaround-for-derivations-store-paths-interpolation
[#202] Provide '^out' suffix for deriver on newer nix
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Since 2.15 nix no longer reference '.drv' as derivation
outputs. At the same time, nix before '2.13' doesn't support '.drv'
special suffix handling.
Solution: Provide '^out' suffix for the profile deriver in case
'nix path-info <...>.drv' returns the same '<...>.drv' path.
In other cases either an error about the build result not being present
in the /nix/store is returned or an actual build result path is
returned.
|
|\ \
| | |
| | | |
[Chore] Handle 'temp_path' as an actual 'Path' instead of 'String'
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: 'temp_path' and 'lock_path' are handled as 'String'.
This can be a problem when the 'temp_path' directory is a symlink
on the target system, e.g. this is the case with the default
'/tmp' and macOS, where this directory is actually a symlink to '/private/tmp'.
Solution: Handle 'temp_path' and 'lock_path' as actual Paths.
Also, canonicalize 'temp_path' to avoid canary file path mismatches when checking
filesystem events.
As a side effect, also update the 'notify' dependency to the latest stable version.
|
|\ \
| |/
|/|
| |
| | |
serokell/rvem/#197-fix-options-handling-with-remote-build
[#197] Fix hostname overriding for remote builds
|
|/
|
|
|
|
|
| |
Problem: '--hostname' is ignored when used with '--remote-build'.
Solution: Account for 'data.deploy_data.cmd_overrides.hostname' when
building a profile remotely.
|
| |
|
|
|
|
|
| |
Try to build everything first before pushing to remotes. Since the build
is more likely to fail than the upload, if there is an error the deployment
will fail sooner and before uploading any potentially unusable configuration.
|
|
|
|
|
|
|
|
| |
flake-compat 64a525ee38 (2022-03-25) -> 009399224d (2022-11-17)
nixpkgs 30d3d79b7d (2022-03-25) -> bb31220cca (2022-12-19)
utils 0f8662f131 (2022-03-26) -> 5aed5285a9 (2022-11-02)
Co-authored-by: Flake Update Bot <operations+update@serokell.io>
Co-authored-by: Alexander Bantyev <balsoft@balsoft.ru>
|
|\
| |
| | |
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).
|
|\ \
| | |
| | | |
Add option to build on the target host
|
|/ / |
|
|\ \
| | |
| | | |
More unique names for the checks generated by deploy-rs
|
|/ /
| |
| |
| | |
Closes #162
|
|\ \
| |/
|/| |
Introduce non-zero exit code for rollbacks
|
|/
|
|
| |
Closes #179
|
|\
| |
| | |
Replace runCommandNoCC by runCommand
|
| |
| |
| |
| |
| |
| |
| | |
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
|
|\
| |
| | |
Update flake to support nix 2.8
|
|/
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Fix a typo
|
|/ |
|
|\
| |
| | |
Automatically update flake.lock to the latest version
|
|/
|
|
|
|
| |
flake-compat b7547d3eed (2022-01-03) -> 64a525ee38 (2022-03-25)
nixpkgs 7f65e4abd5 (2022-01-29) -> 30d3d79b7d (2022-03-25)
utils 846b2ae0fc (2022-01-20) -> 0f8662f131 (2022-03-26)
|
|\
| |
| | |
Automatically update flake.lock to the latest version
|
|/
|
|
|
|
| |
flake-compat 12c64ca55c (2021-08-02) -> b7547d3eed (2022-01-03)
nixpkgs e0ce3c683a (2021-09-19) -> 7f65e4abd5 (2022-01-29)
utils 7e5bf3925f (2021-09-13) -> 846b2ae0fc (2022-01-20)
|