forked from toolshed/docs.coopcloud.tech
		
	| @ -8,6 +8,15 @@ You can run `abra recipe new <recipe>` to generate a new `~/.abra/recipes/<recip | |||||||
|  |  | ||||||
| ## Hacking on an existing recipe | ## Hacking on an existing recipe | ||||||
|  |  | ||||||
|  | !!! warning | ||||||
|  |  | ||||||
|  |     It is *very advisable* to disable any `healthcheck: ...` configuration | ||||||
|  |     while hacking on new recipes. This is because it is very easy to mess up | ||||||
|  |     and it will stop Traefik or other web proxies routing the app. You can | ||||||
|  |     enable a specific healthcheck later when your recipe is stable. The default | ||||||
|  |     "unconfigured" healthcheck behaviour is much less strict and it's faster to | ||||||
|  |     get something up and running. | ||||||
|  |  | ||||||
| If you want to make changes to an existing recipe then you can simply edit the files in `~/.abra/recipes/<recipe-name>` and run pass `--chaos` to the `deploy` command when deploying those changes. `abra` will not deploy unstaged changes to avoid instability but you can tell it to do so with `--chaos`. This means ou can simple hack away on the existing recipe files on your local file system and then when something is working, submit a change request to the recipe upstream. | If you want to make changes to an existing recipe then you can simply edit the files in `~/.abra/recipes/<recipe-name>` and run pass `--chaos` to the `deploy` command when deploying those changes. `abra` will not deploy unstaged changes to avoid instability but you can tell it to do so with `--chaos`. This means ou can simple hack away on the existing recipe files on your local file system and then when something is working, submit a change request to the recipe upstream. | ||||||
|  |  | ||||||
| ## How is a recipe structured? | ## How is a recipe structured? | ||||||
|  | |||||||
		Reference in New Issue
	
	Block a user