Build-Tasks

elide build leitet Tasks aus den Source-Sets und Artefakten in elide.pkl ab und führt sie in Abhängigkeitsreihenfolge aus. Tasks mit unveränderten Eingaben werden übersprungen oder aus dem Cache wiederhergestellt.

Build ausführen

elide build                   # run the default group
elide build compile-java-main # run one task
elide build compile           # run a group
elide build clean             # the clean target
elide build --inspect         # list tasks and their options without running

Ein Argument nennt einen Task oder eine Gruppe; ein führender Doppelpunkt (:compile-java-main) ist optional. Ein Ziel, das auf nichts passt, lässt den Build fehlschlagen.

Manche Tasks nehmen Optionen an, die --inspect auflistet:

elide build test --select=class:com.example.SomeTest
elide build run --args="a b c"

Stellen Sie in einem Workspace das Projekt voran: core:compile-kotlin-main, core:compile oder core für seine Standard-Tasks. Ziele ohne Präfix werden im aktuellen Projekt aufgelöst, dann in der Wurzel. --inspect gruppiert Tasks nach Projekt, und Fortschrittszeilen nennen es ([core] Compiling Kotlin sources).

Optionen

Optionen haben die Form --name oder --name=value und dürfen an beliebiger Stelle zwischen den Zielen stehen. Argumente nach -- gehen an den Prozess, den ein Task startet.

Optionen werden vor der Ausführung gegen die Tasks geprüft. Eine unbekannte Option, ein fehlender oder unerwarteter Wert oder eine wiederholte Option führen zum Fehlschlag:

Unknown option '--worker', did you mean '--workers'?
Option '--workers' requires a value, as '--workers=<value>'

Globale Flags (-p, -v, --debug und die übrigen) sind davon ausgenommen. Task-Optionen: Abhängigkeiten, Tests.

Build-Cache

Die lokale Stufe ist immer aktiv: ~/.elide/cache/entries-v2, ein Verzeichnis pro Schlüssel mit einem Datensatz und einem Tar-Archiv der Ausgaben. Wiederherstellungen werden gegen den gespeicherten Fingerabdruck geprüft. Einträge in einem älteren Format gelten als Fehltreffer.

Die gemeinsame Stufe ist ein HTTP-Cache, der über Umgebungsvariablen eingerichtet wird:

• Der lokale Cache wird zuerst geprüft; Treffer aus dem entfernten Cache werden lokal gespeichert.
• Typische Einrichtung: CI lädt hoch; Entwickler setzen ELIDE_REMOTE_CACHE_PUSH=false.
• Nicht erreichbare, langsame oder unlesbare entfernte Einträge gelten als Fehltreffer. Drei Transportfehler in Folge schalten die Stufe für den Rest des Builds ab. HTTP-Fehler wie 404 sind keine Transportfehler; bei einer abgelehnten Anmeldung erscheint einmal eine Warnung.
• Der Build schlägt fehl bei einer URL, die nicht http/https ist, bei einem Passwort ohne Benutzernamen, bei einem nicht booleschen PUSH/PULL oder bei Anmeldedaten über unverschlüsseltes http zu einem Host außerhalb von Loopback.
• Der Cache liefert ausführbare Ausgaben: Verwenden Sie https, verlangen Sie Authentifizierung für Schreibzugriffe und beschränken Sie, wer schreiben darf.
• --offline schaltet die gemeinsame Stufe für einen Lauf ab; --no-cache schaltet das Caching ab.

.eliderc und die Richtlinie smart

Unter smart wird ein Eintrag nur heruntergeladen, wenn das günstiger ist als ein erneuter Build, und nur hochgeladen, wenn der Upload weniger kostet als die Arbeit, die er einspart. Die Kosten stammen aus .eliderc (java.util.Properties-Syntax): ~/.eliderc, darüber <project>/.eliderc. Die Datei beschreibt die Maschine, committen Sie sie also nicht.

# ~/.eliderc
network.downlink = 200mbps
network.uplink = 20mbps
network.latency = 250ms
network.stability = good        # good | fair | poor
machine.compute = fast          # slow | normal | fast, or a multiplier such as 1.5

cache.remote.policy = smart     # smart | eager (default)
cache.remote.upload-budget = 2.0
cache.remote.min-build = 500ms  # work cheaper than this is never published

Mb/s und mbps sind Megabit; MB/s ist Megabyte. Unlesbare Werte erzeugen eine Warnung, und der Standardwert gilt. ELIDE_REMOTE_CACHE_POLICY überschreibt cache.remote.policy. Unter eager hat die Datei keine Wirkung.

Build-Zustand

• Binärdateien; nicht bearbeiten.
• Es gibt kein Lockfile für Abhängigkeiten aller Ökosysteme; npm schreibt aube-lock.yaml.
• In einem Workspace wird der Zustand aller Mitglieder im .dev/ der Wurzel gespeichert; Ausgaben bleiben im .dev/ des jeweiligen Projekts.
• --no-cache ignoriert die lokale Zustandsdatei, liest aber weiterhin die gemeinsame.
• elide install verwendet die Auflösung wieder, solange sich die Abhängigkeitsliste nicht ändert; --fresh lädt jede Abhängigkeit erneut herunter und frischt so den globalen Cache auf.
• Die Argumente jedes Compilers werden neben seiner Ausgabe als <tool>.args geschrieben, eines pro Zeile.

Build-Zeiten messen

Jeder Task gibt seine Dauer aus. Für mehr Details:

elide build -v                                                # everything, at debug
ELIDE_LOG=dev.elide.tooling.build.telemetry=debug elide build # only the timings

[debug] dev.elide.tooling.build.telemetry stage graph took 590us
[debug] dev.elide.tooling.build.telemetry op compile-kotlin-main · up-to-date (up-to-date) took 420us
[debug] dev.elide.tooling.build.telemetry task compile-kotlin-main (skipped: up-to-date) took 12.6ms

Bereiche sind eine Phase (Konfiguration, Graph, Ausführung, Speichern des Zustands), ein Task oder eine Operation eines Tasks (prepare, fingerprint, up-to-date, execute, Cache-Abfragen und -Speicherungen). Arbeit innerhalb von execute wird nicht weiter aufgeschlüsselt.

ELIDE_BUILD_TELEMETRY schreibt am Ende des Builds einen lokalen Chrome-Trace; nichts wird hochgeladen:

ELIDE_BUILD_TELEMETRY=1 elide build             # .dev/telemetry/build-<stamp>.trace.json
ELIDE_BUILD_TELEMETRY=profile.json elide build  # a file you name
ELIDE_BUILD_TELEMETRY=/tmp/traces elide build   # a directory you name

Öffnen Sie ihn in Perfetto, chrome://tracing oder speedscope, oder:

jq -r '.traceEvents[] | select(.ph=="X") | "\(.dur/1000 | floor)ms \(.cat) \(.name)"' \
  .dev/telemetry/build-*.trace.json | sort -rn | head