BazelCon 2022 findet vom 16. bis 17. November in New York und online statt.
Jetzt anmelden

Hermetik

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite werden Hermetik, die Vorteile von hermetischen Builds und Strategien zur Identifizierung von nicht hermetischen Verhalten in Builds erläutert.

Übersicht

Wenn derselbe Eingabequellcode und dieselbe Produktkonfiguration angegeben werden, gibt ein hermetisches Build-System immer dieselbe Ausgabe zurück, indem der Build von Änderungen am Hostsystem isoliert wird.

Um den Build zu isolieren, sind hermetische Builds nicht empfindlich auf Bibliotheken und andere Software, die auf dem lokalen oder Remote-Hostcomputer installiert ist. Sie hängen von bestimmten Versionen von Build-Tools wie Compilern und Abhängigkeiten wie Bibliotheken ab. Dadurch ist der Build-Prozess eigenständig, da er nicht auf Dienste außerhalb der Build-Umgebung angewiesen ist.

Die beiden wichtigen Aspekte der Hermetik sind:

  • Isolierung: Hermetische Build-Systeme behandeln Tools als Quellcode. Sie laden Kopien von Tools herunter, verwalten ihren Speicher und verwenden sie in verwalteten Dateistrukturen. Dadurch werden der Hostcomputer und der lokale Nutzer isoliert, einschließlich installierter Sprachversionen.
  • Quellidentität: Hermetische Build-Systeme versuchen, die gleiche Eingabe zu gewährleisten. In Code-Repositories wie Git werden CodeMutationen mit einem eindeutigen Hash-Code identifiziert. Hermetische Build-Systeme verwenden diesen Hash, um Änderungen an der Build-Eingabe zu erkennen.

Vorteile

Die wichtigsten Vorteile von hermetischen Builds:

  • Geschwindigkeit: Die Ausgabe einer Aktion kann im Cache gespeichert werden und die Aktion muss nur dann ausgeführt werden, wenn sich die Eingaben ändern.
  • Parallele Ausführung: Für eine bestimmte Eingabe und Ausgabe kann das Build-System ein Diagramm aller Aktionen erstellen, um eine effiziente und parallele Ausführung zu berechnen. Das Build-System lädt die Regeln und berechnet ein Aktionsdiagramm und Hasheingaben, um den Cache zu ermitteln.
  • Mehrere Builds: Sie können mehrere hermetische Builds auf derselben Maschine erstellen, die jeweils unterschiedliche Tools und Versionen enthalten.
  • Reproduzierbarkeit: Hermetische Builds eignen sich gut für die Fehlerbehebung, da Sie die genauen Bedingungen kennen, die zum Erstellen des Builds geführt haben.

Nicht-Hermetik identifizieren

Wenn Sie den Wechsel zu Bazel vorbereiten, ist die Migration einfacher, wenn Sie Ihre vorhandenen Builds im Voraus optimieren. Häufige Ursachen für eine Nicht-Hermetik in Builds sind:

  • Beliebige Verarbeitung in .mk Dateien
  • Aktionen oder Tools, die Dateien nicht-deterministisch erstellen, normalerweise mit Build-IDs oder Zeitstempeln
  • Binärsystemen, die sich je nach Host unterscheiden (z. B. /usr/bin-Binärprogramme, absolute Pfade, System-C++-Compiler für native C++-Regeln zur automatischen Konfiguration)
  • Während der Build-Erstellung in den Quellbaum schreiben Dadurch wird verhindert, dass dieselbe Quellstruktur für ein anderes Ziel verwendet wird. Der erste Build schreibt in die Quellstruktur und korrigiert die Quellstruktur für Ziel A. Dann kann der Versuch, Ziel B zu erstellen, fehlschlagen.

Fehlerbehebung bei nicht hermetischen Builds

Beginnend mit der lokalen Ausführung werden bei Problemen, die lokale Cache-Treffer betreffen, nicht-hermetische Aktionen angezeigt.

  • Achten Sie darauf, dass keine sequenziellen Builds ausgeführt werden: Wenn Sie make ausführen und einen erfolgreichen Build erhalten, sollten bei der erneuten Ausführung des Builds keine Ziele neu erstellt werden. Wenn Sie jeden Build-Schritt zweimal oder auf verschiedenen Systemen ausführen, einen Hash des Dateiinhalts vergleichen und unterschiedliche Ergebnisse erhalten, ist der Build nicht reproduzierbar.
  • Führen Sie Schritte zur Fehlerbehebung bei lokalen Cache-Treffern verschiedener potenzieller Clientcomputer aus, damit Sie alle Fälle von Clientumgebungen erkennen können, die in die Aktionen gelangen.
  • Führen Sie einen Build in einem Docker-Container aus, der nichts außer dem ausgecheckten Quellbaum und der expliziten Liste der Hosttools enthält. Build-Fehler und Fehlermeldungen erfassen implizite Systemabhängigkeiten.
  • Hermetikprobleme mithilfe von Remote-Ausführungsregeln ermitteln und beheben
  • Aktivieren Sie die strikte Sandbox auf Aktionsebene, da Aktionen in einem Build zustandsorientiert sein können und sich auf den Build oder die Ausgabe auswirken können.
  • Mit Arbeitsbereichsregeln können Entwickler Abhängigkeiten zu externen Arbeitsbereichen hinzufügen. Sie sind jedoch reich genug, um eine beliebige Verarbeitung auszuführen. Sie können ein Log einiger nicht hermetische Aktionen in Bazel-Arbeitsbereichsregeln abrufen, indem Sie Ihrem Bazel-Befehl das Flag --experimental_workspace_rules_log_file=PATH hinzufügen.

Hermetik mit Bazel

Weitere Informationen zu den Erfolgen anderer Projekte bei hermetischen Builds mit Bazel finden Sie in diesen BazelCon-Vorträgen: