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).
59 lines
3.2 KiB
Markdown
59 lines
3.2 KiB
Markdown
---
|
|
description: Fetch a Co-op Cloud recipe and check for available upgrades
|
|
argument-hint: <recipe-name>
|
|
allowed-tools: [Bash, Read, Write, Glob, Grep, WebFetch, WebSearch]
|
|
---
|
|
|
|
# Recipe Check
|
|
|
|
Fetch the latest version of a Co-op Cloud recipe and check for available upgrades.
|
|
|
|
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. **Fetch the recipe** — check for uncommitted local changes first (see guidelines). If clean, run `abra recipe fetch $ARGUMENTS --force`. If there are local changes, skip the fetch and note that you're using the local checkout.
|
|
|
|
2. **Show current released versions**:
|
|
```
|
|
abra recipe versions $ARGUMENTS -m
|
|
```
|
|
|
|
3. **Check for available upgrades** (machine-readable, non-interactive):
|
|
```
|
|
abra recipe upgrade $ARGUMENTS -m -n
|
|
```
|
|
|
|
4. **Lint the recipe** to surface any config issues:
|
|
```
|
|
abra recipe lint $ARGUMENTS -C
|
|
```
|
|
|
|
5. **Look up upstream release notes**:
|
|
- Check if `recipe-info/$ARGUMENTS/upstream.md` exists in the workspace.
|
|
- If it exists, read it to get the release notes URLs for each image/service.
|
|
- If it does NOT exist, try to discover the upstream project and release notes URLs:
|
|
- Read the recipe's `compose.yml` to identify all images.
|
|
- For each image, search for its GitHub repository and releases page.
|
|
- Create `recipe-info/$ARGUMENTS/upstream.md` with the discovered URLs (follow the format of existing upstream.md files in sibling recipe directories).
|
|
- Also create the `recipe-info/$ARGUMENTS/tests/` directory if it doesn't exist.
|
|
- For any services that have available upgrades, fetch the release notes page and summarise what changed between the current version and the upgrade version(s).
|
|
- Pay special attention to and explicitly call out:
|
|
- **Breaking changes** — API removals, renamed/removed config options, changed defaults, dropped support for older runtimes/dependencies
|
|
- **Required migration steps** — database migrations, data format changes, manual upgrade procedures
|
|
- **Config changes needed by the operator** — new required environment variables, changed variable names/formats, new secrets, changed ports or volume paths, deprecated settings that will stop working
|
|
- **Dependency version requirements** — e.g. "now requires PostgreSQL 15+", "minimum Redis 6.2"
|
|
- If any of the above are found, present them in a clearly marked "**Operator Action Required**" section per service, separate from the general changelog summary. Use warnings/bold to make these impossible to miss.
|
|
|
|
6. **Summarise the results** for the user:
|
|
- Current version(s) of the recipe
|
|
- Any available image tag upgrades
|
|
- **Operator Action Required** items first (breaking changes, config changes, migrations) — prominently highlighted
|
|
- For each upgrade: a summary of what changed (from release notes), with a link to the full release notes
|
|
- Any lint warnings or errors
|
|
|
|
7. **Suggest next steps** — if upgrades are available, suggest the user run `/recipe-upgrade-plan $ARGUMENTS` to create a detailed upgrade plan.
|