documentation: reorder the position of a few parts

This commit is contained in:
Solene Rapenne 2022-09-27 00:07:09 +02:00
parent 6a7e16bbf2
commit 8d7f17be31
3 changed files with 33 additions and 9 deletions

4
bento
View File

@ -3,7 +3,7 @@
# FUNCTION LIBRARIES
usage() {
cat <<EOF
usage: bento init | deploy | build [test|switch] | status [delay] | flake-update [input]
usage: bento init | deploy | build [dry-run|test|switch] | status [delay] | flake-update [input]
bento init
: create the layout for bento in the current directory
@ -11,7 +11,7 @@ bento init
bento deploy
: build configurations and deploy configuration files, require to be root
bento build [test|switch]
bento build [dry-run|test|switch]
: build configurations, can activate (test or switch) a build locally
bento status [delay]

View File

@ -79,13 +79,7 @@ If you don't want to wait for the timer, you can ssh into the machine to run `sy
Using `bento status`, you instantly get a report of your fleet, all information are extracted from the logs files deposited after each update:
- what is the version they should have (built locally) against the version they are currently running
- their state:
- **sync pending**: no configuration file changed, only files specific to **Bento**
- **rebuild pending**: the local version has been updated and the remote must run `nixos-rebuild`
- **up to date**: everything is fine
- **extra logs**: the update process has been run more than necessary, this shouldn't happen. The most common case is to run the update service manually.
- **failing**: the update process failed
- **rollbacked**: the update process failed and a rollback has been done to previous version. **Bento** won't try until a new configuration is available.
- their current state
- the time elapsed since last rebuild
- the time elapsed since the new onfiguration has been made available

View File

@ -1,3 +1,24 @@
# Usage
- `bento init`
- create the layout for bento in the current directory (only work from flakes)
- `bento deploy`
- build configurations and deploy configuration files, requires to be root
- `bento build [dry-run|build|test|switch]`
- dry-build or build configurations. Using `test` or `switch`, can be used to apply a configuration locally. Default is `build`.
- `bento status [delay]`
- display information for remote hosts, if `delay` is set, loop infinitely to display the status every `delay` seconds. Default delay is `0` and doesn't loop.
- `bento flake-update [input]`
- recursively update flakes lock files
- with [input] parameter it only update the input passed as parameter
- `env NAME=someconfig bento deploy|build`
- only build / deploy the system "someconfig"
# Environment variables
`bento` is using the following environment variables as configuration:
@ -26,3 +47,12 @@ As each host is sending a log upon rebuild to tell if it failed or succeeded, we
Using `bento status` you can track the current state of each hosts (time since last update, current NixOS version, status report)
[![asciicast](https://asciinema.org/a/520504.svg)](https://asciinema.org/a/520504)
# Status list
- **sync pending**: no configuration file changed, only files specific to **Bento** changed
- **rebuild pending**: the local version has been updated and remote will need to run `nixos-rebuild`
- **up to date**: no difference between the local configuration and what the remote system is running
- **extra logs**: the update process has been run more than once, this shouldn't happen. The most common case is that the update service has been started again manually.
- **failing**: the update process failed
- **rollbacked**: the update process failed, but a rollback has been done to previous version. **Bento** won't try to update until a new configuration is available.