Builds mit Cloud Build automatisieren

In diesem Thema wird beschrieben, wie sich Builds mithilfe von Cloud Build und Cloud Source Repositories automatisieren lassen.

Sie können Cloud Build so konfigurieren, dass automatisch jedes Mal ein neues Image erstellt wird, wenn ein Nutzer eine Änderung an Dateien überträgt, die in Cloud Source Repositories gespeichert sind. Ereignisse, die automatische Builds initiieren, werden Build-Trigger genannt. Diese Trigger können dazu beitragen, dass Ihre Container-Images auf dem neuesten Stand bleiben. Sie können auch zum Erstellen und Testen von Feature-Branches verwendet werden.

Vorbereitung

Weitere Informationen

Darüber hinaus könnten die folgenden Informationen hilfreich sein:

  • Build-Trigger verwenden oberflächliche Klone eines Repositorys. Dies bedeutet, dass nur der einzelne Commit, der einen automatischen Build ausgelöst hat, im Arbeitsbereich ausgecheckt wird. Weitere Informationen und Hinweise zur weiteren Verwendung des Repository-Verlaufs finden Sie auf der Seite Oberflächliche Klone aufheben.

  • Wenn Sie einen anderen gehosteten Git-Anbieter wie GitHub oder Bitbucket verwenden und das Repository trotzdem in Cloud Source Repositories spiegeln müssen, benötigen Sie die Berechtigung cloudbuilds.builds.create für das Google Cloud-Projekt, an dem Sie arbeiten. Diese Berechtigung wird normalerweise über die Rolle cloudbuild.builds.editor erteilt.

    Wenn Sie zum ersten Mal einen Build-Trigger mit einem externen Repository erstellen, müssen Sie eine Autorisierung für dieses Repository einrichten. Weitere Informationen finden Sie unter Repository als Remote-Repository hinzufügen.

    Nachdem Sie Ihr externes Repository eingerichtet haben, wird Ihr Repository von Cloud Source Repositories gespiegelt.

  • Informationen zu den Kontingenten und Limits für Cloud Build finden Sie in der Cloud Build-Dokumentation unter Kontingente und Limits.

Build-Trigger erstellen

Gehen Sie so vor, um einen neuen Build-Trigger zu erstellen:

  1. Öffnen Sie in der Google Cloud Console die Cloud Build-Seite Build-Trigger.

    Zur Seite "Build-Trigger"

  2. Wählen Sie Ihr Google Cloud-Projekt aus und klicken Sie auf Öffnen.

    Die Seite Trigger wird geöffnet.

  3. Klicken Sie auf Trigger erstellen.

    Die Seite Trigger erstellen wird geöffnet.

  4. Wählen Sie in der Drop-down-Liste Repository ein Repository aus der Liste der verfügbaren Repositories aus.

  5. Füllen Sie die folgenden Optionen aus:

    • Optional Geben Sie im Feld Beschreibung einen Namen für den Trigger ein.
    • Optional In der Liste Triggertyp können Sie einen Trigger festlegen, um einen Build für Commits zu einem bestimmten Branch oder für Commits mit einem bestimmten Tag zu starten. In beiden Fällen können Sie einen regulären Ausdruck mit dem entsprechenden Branch- oder Tag-Wert festlegen.

    • Wählen Sie in der Liste Build-Konfiguration einen Konfigurationsdateityp aus, der für jeden vom Trigger gestarteten Build verwendet werden soll. Sie können ein Dockerfile auswählen und angeben oder eine Cloud Source Repositories-Konfigurationsdatei auswählen, die sich im Remote-Repository befindet. Sehen Sie sich bei Bedarf die Informationen auf dieser Seite zum Erstellen eines Builds mit einemDockerfile oder einer Build-Konfigurationsdatei an.

  6. Klicken Sie auf Trigger erstellen.

Dockerfile verwenden

Um ein Dockerfile für Ihre Build-Konfiguration zu verwenden, müssen Sie das Dockerfile-Verzeichnis festlegen und einen Namen für das resultierende Image vergeben.

Nachdem Sie das Dockerfile und den Image-Namen angegeben haben, sehen Sie eine Vorschau des docker build-Befehls, den Ihr Build ausführt, und eine Zusammenfassung der Triggerkonfiguration.

Build-Konfigurationsdatei verwenden

Zur Verwendung einer Build-Konfigurationsdatei für Ihre Build-Konfiguration müssen Sie den Speicherort einer Build-Konfigurationsdatei angeben.

Wenn Sie den Speicherort angegeben haben, wird eine Zusammenfassung des Triggers angezeigt.

Build-Trigger testen

Klicken Sie in der Triggerliste neben dem Triggereintrag auf Trigger ausführen, um einen Build-Trigger manuell zu testen.

Build-Trigger überspringen

Wenn Sie beispielsweise Dokumentations- oder Konfigurationsdateien aktualisieren, möchten Sie möglicherweise Ihren Quellcode ändern, aber keinen Build auslösen.

Wenn Sie in solchen Fällen [skip ci] oder [ci skip] in die Commit-Nachricht aufnehmen, wird kein Build ausgelöst.

Beispiel:

Author: A User <auser@example.com>
Date:   Tue Apr 3 12:03:35 2018 -0700

Fixed customer affecting issue. [skip ci]

Wenn Sie später einen Build für diesen Commit ausführen möchten, verwenden Sie die Schaltfläche Trigger ausführen.

Nicht oberflächliche Klone

Zum Erstellen Ihrer Quelle in einem Git-Repository führt Cloud Source Repositories einen "oberflächlichen" Klon des Repositorys aus. Wenn Cloud Source Repositories einen "oberflächlichen" Klon ausführt, wird im Arbeitsbereich nur der einzelne Commit, der den Build ausgelöst hat, geprüft, und dann der Build aus dieser Quelle erstellt. Cloud Source Repositories überprüft keine anderen Branches oder Verläufe. Dies geschieht aus Effizienzgründen. Builds werden nicht verzögert, während Cloud Source Repositories das gesamte Repository und den gesamten Verlauf abruft, um einen Build von einem einzelnen Commit auszuführen.

Wenn Sie einen größeren Teil Ihres Repository-Verlaufs in den Build einbeziehen möchten, fügen Sie einen Build-Schritt zu Ihrer Build-Konfigurationsdatei hinzu, um den "oberflächlichen" Klon aufzuheben. Beispiel:

steps:
- name: gcr.io/cloud-builders/git
  args: ['fetch', '--unshallow']
...

Weitere Informationen zu git fetch finden Sie in der Git-Referenz. Anleitungen zum Schreiben einer Build-Konfigurationsdatei finden Sie in der Übersicht zur Build-Konfiguration.

Weitere Informationen