6da560810f
Two capabilities that make triage useful outside the demo surface. Issues: when triage concludes a human is needed, file an issue in the failing service's own repository carrying classification, confidence, the facts with their sources, the inferences and a Jenkins link, plus a footer stating Hermes has no write access and nothing was changed. Opt-in per job via a repo map, deduplicated by job+classification so a repeatedly failing job yields one issue per kind of failure rather than one per build, and capped per tick. Disabled by default. Real-repo patches: candidate files are selected from the console failure regions (Python, Rust and JS/TS reference patterns), filtered to each repo's allowed prefixes and suffixes, ranked earliest-failure-first with source preferred over test files, and fetched whole - never truncated, because a patch anchor must match exactly. Per-job owner/repo/base-branch resolution; the patch is validated against the file the model actually chose, and an unlisted path is rejected. Legacy single-repo demo behaviour is preserved unchanged. 131 new tests; 472 pass in the hermes suite. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ariadne
Ariadne is the Atlas admin and account automation service.
It sits behind the portal and handles the jobs that are annoying or risky to do by hand: approving access, syncing account state, rotating service passwords, cleaning stale Kubernetes work, checking platform health, and keeping a few service integrations lined up.
How it works
Ariadne is a FastAPI service with a small scheduler. It talks to Keycloak, Vault, Mailu, Nextcloud, Wger, Firefly, Jenkins, Metis, Kubernetes, and a few Atlas-specific services through focused adapters under ariadne/services/.
The API is split between admin routes, account self-service routes, internal event hooks, and Prometheus metrics. Background jobs store run history in the Ariadne database so failures can be inspected later instead of vanishing into logs.
The following are notes for future Brad.
Bring-up dependencies
Ariadne needs:
- Kubernetes API, service DNS, and Ariadne's service account/RBAC
- the Ariadne database, plus the portal database if portal/account sync is enabled
- Vault or the Kubernetes secrets that Vault normally feeds it
- Keycloak/OIDC, because auth and profile sync assume it exists
- ingress/proxy plumbing if humans are going to use it through the portal
- the services for whatever jobs are enabled: Mailu, Nextcloud, Vaultwarden, Wger, Firefly, Jenkins, Metis, OpenSearch, and the comms/game-mode pieces
It can start before every integration is perfect, but the matching scheduled jobs will fail or no-op until their service is actually alive. In a total bring-up, wait for storage, Flux, Postgres, Vault, Keycloak, and ingress first. Afterwards Ariadne becomes useful glue.
Useful routes:
GET /healthGET /metricsGET /api/admin/cluster/statePOST /api/admin/access/requests/{username}/approvePOST /api/account/mailu/rotatePOST /api/account/wger/resetPOST /api/account/firefly/resetPOST /events
Development
python -m pytest
ruff check .
Most runtime behavior is configured through environment variables in ariadne/settings.py. Service-specific logic is in the small adapter modules; ariadne/app.py is focused on request flow and task orchestration.