codex ca5b22b977
All checks were successful
Tests / Declarative: Post Actions passed: 1377
feat(hermes): name the Hermes run in the pull request it produced
The pull request said "Proposed by Hermes" and gave a reader nothing to check
that against. "Hermes made this decision" is a claim; the run id is the
receipt, and without it there is no way to open the run, read the prompt the
model was given, or see the tool calls it made. The diagnosis issues have
carried the run id from the start - the pull requests, which are the more
consequential artifact, did not.

The unused build_number parameter on open_pull_request is what the run id
replaces. That parameter was dead - SonarQube flags it as python:S1172 on this
very repository - so the argument count did not grow.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 23:16:47 -03:00
2026-06-19 21:27:06 +00:00

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 /health
  • GET /metrics
  • GET /api/admin/cluster/state
  • POST /api/admin/access/requests/{username}/approve
  • POST /api/account/mailu/rotate
  • POST /api/account/wger/reset
  • POST /api/account/firefly/reset
  • POST /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.

Description
atlas cluster job management tool with reporting for prometheus
Readme 4.4 MiB
Languages
Python 100%