recipe-maintainers/recipe-maintainer
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
460eba090ba6765b05a929d32d16ca984cf66e5a
recipe-maintainer/.claude/commands/sync-secrets.md
autonomic-bot f283a371bb recipe-maintainer: public snapshot (secrets + deployment plans removed, single commit) 
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).
2026-06-16 20:18:24 +00:00

3.2 KiB
Raw Blame History

description, argument-hint, allowed-tools
description argument-hint allowed-tools
Sync Docker secrets from the test server into recipe-info/testsecrets/
recipe-name
Bash
Read
Grep
Glob

Sync Secrets

Deploy each app on the current test instance one at a time, read its Docker secrets from the running containers, update the local recipe-info/testsecrets/ file, then undeploy the app before moving on to the next.

The optional recipe name is: $ARGUMENTS

Read and follow the instructions in .claude/commands/includes/logging.md.

Background

Each recipe's Docker secrets are mounted at /run/secrets/ inside containers. The recipe-info/testsecrets/<domain> files store these values locally so that setup scripts (via lib/secrets.py) can look them up dynamically. When secrets are regenerated on the server or you switch test instances, the local files become stale — this skill re-syncs them by deploying each app temporarily to read its secrets.

Steps

  1. Check prerequisites:

    • Read settings.toml to confirm the active test instance (or run python3 scripts/get_test_instance.py to check).
    • Verify SSH connectivity to the server: ssh <server> echo ok
    • Ensure the ssh-agent has the key loaded. If SSH fails, run: 
      eval "$(ssh-agent -s)" && ssh-add /workspace/test-ssh/test-ssh-keys/nptest

  2. Build the recipe list:

    • If a recipe name was provided in $ARGUMENTS, use only that recipe.
    • Otherwise, find all recipes that have a recipe-info/<recipe>/recipe.toml file.
    • Get the domain for each recipe by running: python3 scripts/get_test_instance.py --recipe <recipe>

  3. Check which apps are already running — run:

    abra app ls --server <instance>.commoninternet.net -S -m

    Parse the output to build a list of apps that are already deployed. These will NOT be undeployed after syncing (we leave them as we found them).

  4. For each recipe, sequentially:

    a. Deploy the app (if not already running):

    abra app deploy <domain> --chaos --force --no-input

    Wait for it to converge. If the deploy fails, log the error, skip this recipe, and continue to the next.

    b. Wait for containers — give services a moment to start (10-15 seconds), then verify at least one container is running:

    ssh <server> "docker ps -q --filter 'name=<stack>_' | head -1"

    The stack name is the domain with dots replaced by underscores (e.g. <recipe>.<DOMAIN_SUFFIX> → <recipe>_<DOMAIN_SUFFIX_WITH_UNDERSCORES>).

    c. Read secrets — run the sync script for this recipe:

    python3 scripts/sync_secrets.py --recipe <recipe>

    d. Undeploy (only if the app was NOT already running before step 3):

    abra app undeploy <domain> --no-input

    e. Log the result for this recipe before moving to the next.

  5. Verify — spot-check one or two updated testsecrets files by reading them and confirming the values look like real secrets (not empty or error messages).

  6. Summarise — tell the user:

    • Which instance was synced (<instance>.commoninternet.net).
    • How many recipes were synced vs failed.
    • Which apps were left running (because they were already deployed before the sync).