Skip to content
Apothem
Architektur

Installations-Workflow

Wie apothem install, update und uninstall durchgängig funktionieren.

Installationsablauf

flowchart TD
    accTitle: Apothem install workflow
    accDescr: Top-down flowchart of the apothem install command from CLI invocation through adapter lookup, profile load, adapter install call, native config write, and final apothem verify check.
    A[apothem install --harness X] --> B[Resolve adapter through registry]
    B --> C[Load and validate profile YAML<br/>before writes]
    C --> D[Adapter.install(profile, project)]
    D --> E[Write native config and support cohorts]
    E --> F[apothem verify --harness X]
    F --> G{All checks pass?}
    G -- yes --> H[Done]
    G -- no --> I[Report failures]

Aktualisierungsablauf

Bei apothem update --harness X:

  1. Lädt und validiert ~/.config/apothem/profile.yaml oder --profile PATH.
  2. Löst den ausgewählten Harness oder all über das zentrale Register auf.
  3. Validiert den vollständigen Materialisierungsplan vor dem ersten Schreibvorgang.
  4. Ruft Adapter.update(profile, project=...) auf.
  5. Meldet die Ergebnisse erstellt, aktualisiert, unverändert, übersprungen, Warnung und Fehler.

Deinstallationsablauf

Bei apothem uninstall --harness X:

  1. Ruft Adapter.uninstall() auf.
  2. Der Adapter entfernt nur die von ihm geschriebenen Dateien; das gemeinsame Profil-YAML und nicht zugehörige, vom Operator verfasste Dateien bleiben unberührt.

Geltungsbereich-Auflösung

Jeder Adapter schreibt in seine eigene feste Installationswurzel: das Benutzer-Home für Adapter mit Benutzergeltungsbereich und der projektlokale Pfad für Adapter mit Projektgeltungsbereich. Die CLI stellt kein --scope-Flag bereit; Adapter mit Projektgeltungsbereich erfordern --project <path>. Jedes Ziel ist unter site/content/docs/harnesses/<harness>.mdx dokumentiert.

Fehlerbehandlung

Installations-/Aktualisierungsvorgänge validieren vor dem Schreiben, sichern vorhandene übereinstimmende Ziele vor dem Ersetzen und führen in gemeinsamen Discovery-Verzeichnissen nur von Apothem verwaltete Untereinträge zusammen. --dry-run führt dieselbe Validierung aus und gibt übersprungene oder unveränderte Ergebnisse zurück, ohne Verzeichnisse oder Dateien zu erstellen.

Reversibility (backup and rollback)

Every install pass is reversible. Replaced bytes are captured into the Apothem backup root and the pass is recorded in the harness ledger under a ULID install id; apothem rollback selects a recorded pass and restores those captured backups.

%% provenance: hand-authored %%
%% verified: 2026-07-06 %%
%% cross-reference: this page's Error handling section (back up before replace); /docs/cli-reference/rollback %%
flowchart LR
    accTitle: Apothem backup and rollback lifecycle
    accDescr: At install time each replaced target's prior bytes are captured into the Apothem backup root and the pass is recorded in the harness ledger under a ULID install id. The rollback command selects a recorded install pass by latest or install-id, restores every captured backup from the backup root, and appends a rollback record to the ledger.
    subgraph Install
        direction TB
        I1["Back up existing targets<br/>before replacement"] --> I2["Apothem backup root"]
        I1 --> I3["Ledger install record<br/>ULID install-id"]
    end
    subgraph Rollback
        direction TB
        R1["Select install pass<br/>--last or --install-id ULID"] --> R2["Restore captured backups<br/>from the backup root"]
        R2 --> R3["Append rollback record<br/>to the harness ledger"]
    end
    I2 -.->|captured bytes| R2
    I3 -.->|resolves pass| R1

On this page