recipe-maintainers/cc-ci-orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8df32edfcf6d7a679ef3e44ecf5eda47626ded6a
cc-ci-orchestrator/.opencode/skills/help/SKILL.md
T
autonomic-bot b0bdce2c15 add /cve-check and /cve-check-and-upgrade 
/cve-check answers 'what are we exposed to that an upgrade would fix?' without
running an upgrade: per-recipe, resolve the available window for EVERY image
(sidecars included), run the advisory scan over it, adjudicate whatever pass 1
could not decide, publish a report. Read-only — no PRs, no CI, no merges.

/cve-check-and-upgrade does that sweep, then runs /recipe-upgrade only on the
recipes whose upgrade actually closes a CVE, worst severity first, and reports
on both. --min-severity high for just the urgent ones; --dry-run prints the
queue and stops. Never merges.

Deliberate choices, each written into the skills:
- externals are SWEPT but never upgraded here — a security sweep that skipped
  deployed software would misreport exposure, but we don't maintain them.
- an unknown count never justifies an upgrade AND is never treated as clean;
  it goes to the Addendum.
- no upgrade available means 0 CVEs, not '?'.
- subagents are told which CVEs justify their upgrade, so the PR says why it
  exists — a PR naming the RCE it closes gets reviewed sooner.

recipe-report.py grows a page kind: 'cve' files as cve-DATE.html so a sweep
can't overwrite a weekly edition, while BOTH appear in the same archive index,
suffixed 'full report' / 'CVE check'.

/help and /cc-ci-status updated to route to them.
2026-08-11 04:04:59 +00:00

6.2 KiB
Raw Blame History

name, description
name description
help Operator orientation - lists every skill available on this orchestrator with what it does and when to reach for it, grouped by purpose (status, weekly maintenance, host updates, tests, enrollment, recovery, reporting), plus a "what do you want to do?" guide for common situations. Read-only. Invoke as /help.

help

Orient the operator: what this orchestrator can do, via which skill, and what's sensible next.

First, enumerate the live roster (skills get added — don't trust this file's list blindly):

ls /srv/cc-ci-orch/.opencode/skills/    # canonical definitions (one dir per skill)

For any skill not described below, read its SKILL.md frontmatter description and include it. Then present the roster grouped as follows, and close with the situation guide.

The roster (curated descriptions — merge with the live listing)

Status & orientation

  • /cc-ci-status — the comprehensive read-only health/status check: weekly-run outcomes, report publishing, stale tests, CVE-PR aging, host update recency, service health, bridge !testme path. Ends ALL HEALTHY or prioritized findings each mapped to a skill. Start here when unsure.
  • /help — this orientation.

Weekly maintenance (recipes)

  • /upgrade-all — the weekly sweep: survey every weekly recipe, open verified upgrade PRs, write the summary + report. Runs on a timer (cc-ci-upgrade-all.timer, Fri 02:00 UTC); invoke manually to run it now.
  • /recipe-upgrade — the same pipeline for ONE recipe (plan → bump → verify green → PR). --with-tests also fixes that recipe's stale test.
  • /recipe-report — (re)generate the weekly report page for report.ci.commoninternet.net.

Security (CVEs)

  • /cve-check — fleet-wide CVE sweep with no upgrading: for every recipe, work out what upgrade is available (per image, sidecars included), scan it for CVEs, and publish a CVE report. Read-only and quick — the "what are we exposed to?" answer without an upgrade run.
  • /cve-check-and-upgrade — the same sweep, then open verified PRs only for the recipes whose upgrade actually fixes a CVE, worst severity first. --min-severity high for just the urgent ones. Never merges.

Tests

  • /cc-ci-tests-update — fleet-wide stale-test cleanup: find tests broken by legitimate upstream changes, fix without weakening, verify, merge the test PRs.
  • /ci-test-review — diagnose a specific red CI run: classify recipe bug vs stale test vs CI-server bug, then fix on the right side.

cc-ci itself

  • /cc-ci-server-update — bump the CI server host's nixpkgs/sops-nix, deploy with build → nixos-rebuild test → switch + health gate, PR merged on green.
  • /cc-ci-orchestrator-update — same for this orchestrator host (self-update caveats).
  • /cc-ci-update — both of the above plus /cc-ci-tests-update in one pass.
  • /ci-dev-workflow — harness/CI-server development discipline (changing cc-ci itself).

Enrollment

  • /recipe-enroll — add a NEW recipe to the maintained set end-to-end: mirror, test suite, bridge + inventory enrollment, full-suite-green verification, bridge deploy.

Recovery

  • hetzner-server-recovery — when a Hetzner host is unreachable over SSH/tailscale: API reboot, rescue mode, GRUB generation selection (submenu ids are 1>N), console access.

Recipe-maintainer toolkit (/cctest-* — the ARM sandbox + cctest test server, NOT cc-ci) The full autonomic-recipe-maintainer skill set, vendored as a pinned submodule (references/recipe-maintainer) and exposed with the cctest- prefix — ~30 skills for hands-on recipe work against the recipe-maintainer cctest test server and local abra sandbox: /cctest-intro (start here), /cctest-recipe-overview, /cctest-recipe-init, /cctest-recipe-deploy, /cctest-recipe-test*, /cctest-recipe-upgrade-plan|apply|full, /cctest-new-recipe-guide, sandbox/instance management (/cctest-setup-sandbox, /cctest-t1cc-start|stop), and more — enumerate with ls .opencode/skills | grep ^cctest-. Rule of thumb: verifying/shipping against the CI pipeline → the cc-ci skills above; exploratory or hands-on recipe development on a test instance → /cctest-*. Policy is unified: recipe PRs are never agent-merged on either side (operator reviews + merges), and ARM skills never touch cc-ci infra. After a submodule bump run scripts/gen-cctest-skills.py.

"What do you want to do?"

Situation Do this
"How is everything?" /cc-ci-status
"Run the weekly upgrades now" /upgrade-all (or systemctl start cc-ci-upgrade-all.service)
"Upgrade just " /recipe-upgrade <recipe>
"The report site is stale/missing a week" /recipe-report
"What CVEs are we exposed to right now?" /cve-check (read-only, no PRs)
"A CVE just dropped — check and patch it" /cve-check-and-upgrade (add --min-severity high to skip the noise)
"Is vulnerable?" /cve-check <recipe>
"Tests are red because upstream changed" /cc-ci-tests-update (fleet) or /recipe-upgrade <r> --with-tests
"A CI run failed and I don't know why" /ci-test-review
"Update the CI server OS/deps" /cc-ci-server-update
"Update this orchestrator's OS/deps" /cc-ci-orchestrator-update
"Add to what we maintain" /recipe-enroll <recipe>
"A host is unreachable" hetzner-server-recovery
"Hack on / bootstrap a recipe in a sandbox" /cctest-recipe-init, /cctest-recipe-deploy, /cctest-recipe-test
"New to recipe work, where do I start?" /cctest-intro
"What needs my review?" /cc-ci-status → its open-PR section lists CVE-urgent + ready-to-merge PRs

Standing conventions (all skills follow these): PRs are opened for visibility and merged directly once verified (invocation = authorization) — except recipe upgrade PRs, which stay operator-merged; nixos-rebuild test before any switch; never weaken a test; single-writer branches; serialize deploy-heavy work on the shared swarm.

If several things need doing, run /cc-ci-status first — its findings come pre-prioritized with the skill to invoke for each.

Reference in New Issue View Git Blame Copy Permalink