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

Bazel aus Skripts aufrufen

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

Sie können Bazel aus Skripts aufrufen, um einen Build auszuführen, Tests auszuführen oder die Abhängigkeitsgrafik abzufragen. Bazel wurde für ein effizientes Skripting entwickelt, aber in diesem Abschnitt finden Sie einige Details, die Sie beachten sollten, um Ihre Skripts robuster zu machen.

Ausgabebasis auswählen

Mit der Option --output_base wird gesteuert, wo der Bazel-Prozess die Ausgaben eines Builds sowie verschiedene intern von GCDS verwendete Arbeitsdateien schreiben soll. Eine Sperre ist eine Sperre, die die gleichzeitige Mutation von durch mehrere Bazel-Prozesse.

Die Auswahl des richtigen Ausgabebasisverzeichnisses für Ihr Skript hängt von mehreren Faktoren ab. Wenn Sie die Build-Ausgaben an einem bestimmten Speicherort ablegen müssen, hängt dies von der zu verwendenden Ausgabebasis ab. Bei einem schreibgeschützten Aufruf an Bazel (z. B. bazel query) sind die Sperrfaktoren wichtiger. Wenn Sie mehrere Instanzen Ihres Skripts gleichzeitig ausführen müssen, müssen Sie jeder Instanz eine andere (oder eine zufällige) Ausgabebasis zuweisen.

Wenn Sie den Standardwert der Basis-Ausgabe verwenden, konkurrieren Sie um dieselbe Sperre, die von den interaktiven Bazel-Befehlen des Nutzers verwendet wird. Wenn der Nutzer länger andauernde Befehle wie Builds ausgibt, muss Ihr Skript warten, bis diese Befehle abgeschlossen sind, bevor es fortfahren kann.

Hinweise zum Servermodus

Standardmäßig verwendet Bazel einen lang andauernden Serverprozess zur Optimierung. Vergessen Sie beim Ausführen von Bazel in einem Skript nicht, shutdown aufzurufen, wenn Sie mit dem Server fertig sind. Alternativ können Sie --max_idle_secs=5 angeben, damit inaktive Server sofort heruntergefahren werden.

Welchen Exit-Code erhalte ich?

Bazel versucht, Fehler aufgrund des zu berücksichtigenden Quellcodes von externen Fehlern zu unterscheiden, die eine ordnungsgemäße Ausführung von Bazel verhindern. Die Ausführung von Bazel kann zu folgenden Exit-Codes führen:

Benutzerdefinierte Exit-Codes für alle Befehle:

  • 0 – Erfolg
  • 2 – Befehlszeilenproblem, fehlerhafte oder ungültige Flags oder Befehlskombination oder schlechte Umgebungsvariablen. Ihre Befehlszeile muss geändert werden.
  • 8 – Build wurde unterbrochen, aber wir haben das Herunterfahren abgebrochen.
  • 9: Die Serversperre ist gehalten und --noblock_for_lock wurde übergeben.
  • 32 – Fehler auf der externen Umgebung, das nicht auf diesem Computer vorhanden ist

  • 33: Der Arbeitsspeicher von Bazel ist beendet und die Anwendung ist abgestürzt. Sie müssen die Befehlszeile ändern.

  • 34 – Für die interne Verwendung bei Google reserviert.

  • 35 – Für die interne Verwendung bei Google reserviert.

  • 36 – Problem mit der Umgebung vor Ort, vermutlich dauerhaft.

  • 37 – Nicht behandelte Ausnahme / interner Bazel-Fehler.

  • 38 – Für die interne Verwendung bei Google reserviert.

  • 41-44 – Für die interne Verwendung bei Google reserviert.

  • 45 – Fehler beim Veröffentlichen der Ergebnisse im Build Event Service.

  • 47 – Für die interne Verwendung bei Google reserviert.

Rückgabecodes für die Befehle bazel build und bazel test:

  • 1 – Build fehlgeschlagen.
  • 3 – Build ist OK, aber einige Tests sind fehlgeschlagen oder es ist eine Zeitüberschreitung aufgetreten.
  • 4 – Build erfolgreich erstellt, aber es wurden keine Tests gefunden, obwohl Tests angefordert wurden.

Für bazel run:

  • 1 – Build fehlgeschlagen.
  • Wenn der Build erfolgreich ist, der ausgeführte Unterprozess jedoch einen Exitcode ungleich null zurückgibt, ist es auch der Exitcode des Befehls.

Für bazel query:

  • 3: Teilweiser Erfolg. Bei der Abfrage ist jedoch mindestens ein Fehler in der BUILD-Eingabedatei aufgetreten. Die Ergebnisse des Vorgangs sind daher nicht zu 100 % zuverlässig. Dies ist wahrscheinlich auf eine --keep_going-Option in der Befehlszeile zurückzuführen.
  • 7 – Befehlsfehler.

Zukünftige Bazel-Versionen können zusätzliche Exit-Codes hinzufügen. Dabei wird der generische Fehler-Exit-Code 1 durch einen anderen Wert ungleich null mit einer bestimmten Bedeutung ersetzt. Allerdings sind alle Nicht-Null-Exit-Werte immer ein Fehler.

.bazelrc-Datei lesen

Standardmäßig liest Bazel die Datei .bazelrc aus dem Basisarbeitsverzeichnis oder dem Basisverzeichnis des Nutzers. Ob dies wünschenswert ist, ist eine Wahl für Ihr Skript. Wenn Ihr Skript perfekt hermetisch sein muss (z. B. beim Ausführen von Release-Builds), sollten Sie das Lesen der .bazelrc-Datei mit der Option --bazelrc=/dev/null deaktivieren. Wenn Sie einen Build mit den bevorzugten Einstellungen des Nutzers ausführen möchten, ist das Standardverhalten besser.

Befehlslog

Die Bazel-Ausgabe ist auch in einer Befehlsprotokolldatei verfügbar, die Sie mit dem folgenden Befehl finden:

bazel info command_log

Die Befehls-Logdatei enthält die verschränkten stdout- und stderr-Streams des letzten Bazel-Befehls. Beachten Sie, dass mit dem Ausführen von bazel info der Inhalt dieser Datei überschrieben wird, da er dann zum neuesten Bazel-Befehl wird. Der Speicherort der Befehls-Logdatei ändert sich jedoch nur, wenn Sie die Einstellungen der Optionen --output_base oder --output_user_root ändern.

Ausgabe wird geparst

Die Bazel-Ausgabe lässt sich für viele Zwecke relativ einfach parsen. Zwei Optionen, die für Ihr Skript hilfreich sein können, sind --noshow_progress, das Fortschrittsnachrichten unterdrückt, und --show_result n, die steuert, ob "aktuelle Nachrichten" ausgegeben werden soll ; Diese Meldungen können geparst werden, um festzustellen, welche Ziele erfolgreich erstellt wurden und an welchem Ort die erstellten Ausgabedateien gespeichert sind. Achten Sie darauf, einen sehr hohen Wert von n anzugeben, wenn Sie sich auf diese Nachrichten verlassen.

Fehlerbehebung durch Profilerstellung

Weitere Informationen finden Sie im Abschnitt Leistungsprofilierung.