Sanitized single-commit public mirror of recipe-maintainer. - Removed test-ssh/.testenv (live creds); added test-ssh/.testenv.example placeholders. - Removed plans/ and planned-updates/ (deployment-planning docs) so no client/ deployment domains appear in the public repo. - All other secret stores were already gitignored. - docs.coopcloud.tech retained as a submodule (public upstream).
117 lines
4.2 KiB
Markdown
117 lines
4.2 KiB
Markdown
---
|
|
description: Deploy all maintained recipes to the active test instance from scratch
|
|
allowed-tools: [Bash, Read, Write, Edit, Glob, Grep, WebFetch]
|
|
---
|
|
|
|
# Init Instance
|
|
|
|
Deploy all maintained recipes to the active test instance in dependency order. Apps that already exist are deployed as-is. Apps that don't exist yet are created following their `setup.md`.
|
|
|
|
Read and follow the instructions in `.claude/commands/includes/logging.md`.
|
|
Read and follow the instructions in `.claude/commands/includes/guidelines.md`.
|
|
|
|
## Steps
|
|
|
|
### 1. Determine the active instance
|
|
|
|
Run `python3 scripts/get_test_instance.py` to get SERVER and INSTANCE. Read `settings.toml` to get `domain_suffix`.
|
|
|
|
### 2. Discover all recipes
|
|
|
|
Glob `recipe-info/*/recipe.toml`. For each, read the file to get:
|
|
- `name` — the recipe name
|
|
- `[dependencies].requires` — list of recipe dependencies (may be empty or absent)
|
|
|
|
### 3. Topological sort — build deployment tiers
|
|
|
|
Group recipes into tiers based on their `[dependencies].requires`:
|
|
|
|
- **Tier 1** (no dependencies): recipes with empty or missing `requires`
|
|
- **Tier 2** (depends on tier 1): recipes whose `requires` list only contains tier 1 recipes
|
|
|
|
Present the deployment order to the user and **confirm before proceeding**.
|
|
|
|
### 4. Deploy each recipe in dependency order
|
|
|
|
Process recipes **one at a time** within each tier. For each recipe:
|
|
|
|
#### a. Free memory
|
|
|
|
Run context reset to undeploy everything except infrastructure and this recipe's dependencies:
|
|
```bash
|
|
python3 scripts/context_reset.py --recipe <recipe>
|
|
```
|
|
|
|
#### b. Compute domain
|
|
|
|
The domain is `<recipe>.<DOMAIN_SUFFIX>`.
|
|
|
|
#### c. Ensure dependencies are deployed
|
|
|
|
If the recipe has dependencies (from recipe.toml), check that each dependency is deployed:
|
|
- Check if `~/.abra/servers/<SERVER>/<dep-domain>.env` exists.
|
|
- If a dependency's env file does NOT exist, follow its `setup.md` first before continuing with the current recipe.
|
|
- If the env file exists, deploy the dependency: `abra app deploy <dep-domain> --chaos --force --no-input`
|
|
|
|
#### d. Check if this app already exists
|
|
|
|
Check for the env file: `~/.abra/servers/<SERVER>/<recipe>.<DOMAIN_SUFFIX>.env`
|
|
|
|
#### e. If the app does NOT exist — create it following setup.md
|
|
|
|
Read `recipe-info/<recipe>/setup.md` and follow every step. Replace `<SERVER>`, `<DOMAIN_SUFFIX>`, and any other placeholders with the actual values from step 1.
|
|
|
|
This covers:
|
|
- `abra app new` with correct flags
|
|
- Secret generation (save to `recipe-info/testsecrets/`)
|
|
- Any env file overrides needed before deploy
|
|
- `abra app deploy`
|
|
- Post-deploy steps (migrations, buckets, etc.)
|
|
- SSO integration setup script if applicable
|
|
- Redeploy after SSO if needed
|
|
|
|
#### f. If the app already exists — just deploy it
|
|
|
|
Do NOT recreate the app, remove secrets, or regenerate secrets. Simply deploy what's there:
|
|
|
|
```bash
|
|
abra app deploy <domain> --chaos --force --no-input
|
|
```
|
|
|
|
If the deploy fails (e.g. missing secrets, bad env config, services won't start), then the existing setup is broken. In that case, clean up and start fresh:
|
|
1. `abra app undeploy <domain> --no-input`
|
|
2. `abra app volume remove <domain> --force --no-input`
|
|
3. Remove secrets: `abra app secret remove <domain> --all --no-input` (TTY-wrapped)
|
|
4. Remove the env file
|
|
5. Follow setup.md from scratch (step e)
|
|
|
|
If the recipe has an SSO setup script and SSO credentials file doesn't exist yet, also run the SSO setup and redeploy.
|
|
|
|
#### g. Sync secrets locally
|
|
|
|
After deploy, if secrets are NOT already saved locally in `recipe-info/testsecrets/<domain>`, sync them from the running containers:
|
|
|
|
```bash
|
|
python3 scripts/sync_secrets.py --recipe <recipe>
|
|
```
|
|
|
|
Do NOT remove or regenerate secrets on the server. This only reads secrets from running containers and saves them locally.
|
|
|
|
#### h. Log result
|
|
|
|
Log PASS if deploy succeeded and health check passes, FAIL otherwise.
|
|
|
|
### 5. Summary table
|
|
|
|
After all recipes are processed, print a summary:
|
|
|
|
| Recipe | Tier | Status | Notes |
|
|
|--------|------|--------|-------|
|
|
| keycloak | 1 | PASS/FAIL | ... |
|
|
| authentik | 1 | PASS/FAIL | ... |
|
|
| ... | ... | ... | ... |
|
|
|
|
### 6. Suggest testing
|
|
|
|
After all recipes are deployed, suggest the user run `/recipe-test <recipe>` for each recipe to verify everything is working. List the recipes in the same dependency order used for deployment.
|