75c7ac10c7
Issue #2 on bstein/ariadne cites its evidence as "console_failures marker '=== FAILURES ===' at line 1949". That is precise and unusable: the maintainer has to open Jenkins, find build 408, scroll a 2000-line console and reconstruct what the diagnosis had already read. The whole point of filing an issue is that someone can act on it without doing that. The traceback was not merely unrendered - it was never collected. The junit query asked for errorDetails and not errorStackTrace, so the bundle carried the assertion that failed but not the line it failed on, and no amount of rendering would have found it. Both halves are fixed: the trace is fetched and bounded, and the issue now opens an Evidence section with it. Console regions are the fallback for a build that published no test results, clipped to their last lines because the tail of a failure region holds the failure while the head only approaches it. A fence inside an excerpt is escaped so raw log text cannot break out of the code block and spill into the rendered page. Bounded deliberately. The body has a hard character budget, and an issue that spends it on console noise buries the one sentence saying why a person is needed. Co-Authored-By: Claude Opus 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.