Compare commits

...

5 Commits

Author SHA1 Message Date
c371faa453 minor changes 2026-03-23 13:13:09 +01:00
186f8b117b info about cleaning up the server 2026-03-22 01:55:16 +01:00
edb6fe93d7 merge upstream 2026-03-22 00:45:38 +00:00
ac7940437b merge upstream 2026-03-21 16:40:35 +00:00
5b55e79a93 Added some info about editor as config setting 2026-01-04 22:29:23 +00:00

View File

@ -96,6 +96,8 @@ make link
## Configure `abra` with `abra.yml`
You can place an `abra.yml`-file in the root of your `$ABRA_DIR`.
There are few configuration options supported at this time but more can be added. We are open to requests!
### `$ABRA_DIR`
@ -106,7 +108,7 @@ The lookup logic is defined like so.
* look for config file and take value from there
* $HOME/.abra as fallback
If you create an `abra.yml` file in your `$PWD` with the following contents.
If you create an `abra.yml` file in your `$PWD` (print working directory) with the following contents.
```
abraDir: .
@ -114,6 +116,12 @@ abraDir: .
Then `$ABRA_DIR` will be automatically picked up as `$PWD`. This is useful when you maintain multiple project configurations and recipes in various state of chaos and would like to separate those. `abra` will create all the usual `$HOME/.abra` state (`servers`/`recipes`/etc.) under your chosen `abraDir` value. This allows you to have multiple independent versions of specific recipes which are relevant for specific projects vs. relying on a single `$ABRA_DIR/recipes/<recipe>` and constantly having to switch between different chaotic hacks.
### `$EDITOR`
When you edit `.env.sample` files, you are asked to chose an editor. To avoid answering that question all the time, you can either set an environment variable (`export EDITOR=nano`), or you can set it as a config-option in abra.yml, like this:
`editor: nano`
## Running abra server side
If you're on an environment where it's hard to run Docker, or command-line programs in general, you might want to install `abra` on a server instead of your local computer.
@ -687,3 +695,13 @@ present.
However, it is otherwise **ignored** for the version candidate. The "source of
truth" for the version candidate is the live deployment of the app.
### Clean up the server
When you have deployed and undeployed apps, or when you have updated apps, docker will not automatically remove the images and containers. At some point your disk will be full, and you get strange errors when trying to deploy new apps.
Log into your server with `ssh`.
You can view all information about containers and images using the command `docker system df -v`. You might see images used by 0 containers and DEAD and exited containers.
If you are *completely* SURE that you have deployed all the apps, you want to keep, you can remove all dead and unused images and containers with the command `docker system prune --all --force` (or `DOCKER_CONTEXT=<server-domain> docker system prune --all --force` if you have multiple docker contexts).