autonomic-bot
f283a371bb
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).
60 lines
2.6 KiB
Markdown
60 lines
2.6 KiB
Markdown
---
|
|
description: Test upgrading a recipe's test instance using abra app deploy
|
|
argument-hint: <recipe-name>
|
|
allowed-tools: [Bash, Read, Write, Glob, Grep, WebFetch]
|
|
---
|
|
|
|
# Recipe Test Update
|
|
|
|
Deploy updated recipe images to an already-running test instance and verify the upgrade works. Combines `/recipe-deploy` and `/recipe-test` with pre-flight checks to confirm the version is actually changing.
|
|
|
|
The recipe name is: $ARGUMENTS
|
|
|
|
Read and follow the instructions in `.claude/commands/includes/logging.md`.
|
|
Read and follow the instructions in `.claude/commands/includes/guidelines.md`.
|
|
|
|
## Steps
|
|
|
|
1. **Get the domain and server for this recipe**:
|
|
```
|
|
python3 scripts/get_test_instance.py --recipe $ARGUMENTS
|
|
```
|
|
This outputs DOMAIN and SERVER for the active instance.
|
|
- If the recipe has no `recipe-info/$ARGUMENTS/recipe.toml`, tell the user to run `/recipe-init $ARGUMENTS` first and stop.
|
|
|
|
2. **Check preconditions**:
|
|
- Verify the app is currently deployed: `abra app ps <DOMAIN> --chaos --no-input -m`.
|
|
- If the app is not deployed, tell the user to run `/recipe-deploy $ARGUMENTS` first and stop — we need a running instance to upgrade.
|
|
- Note the currently deployed version from the `ps` output.
|
|
|
|
3. **Read the new version** from `~/.abra/recipes/$ARGUMENTS/compose.yml`:
|
|
- Find the `coop-cloud.${STACK_NAME}.version=...` label to get the new recipe version string.
|
|
- If the new version matches the currently deployed version, tell the user there's nothing to upgrade and stop.
|
|
- Show the user what's changing: old version → new version.
|
|
|
|
4. **Deploy the update** by following the `/recipe-deploy` process for `$ARGUMENTS`.
|
|
|
|
5. **Wait for the app to stabilise**:
|
|
- Wait 30 seconds, then check status: `abra app ps <DOMAIN> --chaos --no-input -m`.
|
|
- Allow up to 90 seconds total for all services to reach "running" state.
|
|
- If services are not healthy after 90 seconds, note this but continue to tests.
|
|
|
|
6. **Run the test suite** by following the `/recipe-test` process for `$ARGUMENTS`.
|
|
|
|
7. **Summarise results**:
|
|
|
|
| Phase | Result |
|
|
|-------|--------|
|
|
| Pre-upgrade status | deployed at version X |
|
|
| Deploy update | PASS / FAIL |
|
|
| Post-upgrade health | PASS / FAIL |
|
|
| Test suite | PASS / FAIL (detail per test) |
|
|
|
|
**If all tests passed:**
|
|
- Confirm the update works.
|
|
- Suggest committing and tagging the recipe if not already done, then pushing when ready.
|
|
|
|
**If the deploy or any tests failed:**
|
|
- Report what failed with relevant error output and suggest troubleshooting.
|
|
- Note that the previous version can be restored by fetching the recipe (`abra recipe fetch $ARGUMENTS --force`) and redeploying.
|