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.

Build-Trigger können einen Build basierend auf einem Dockerfile oder einer Build-Konfigurationsdatei ausführen.

Verwendung eines Dockerfiles

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. Weitere Informationen zum Erstellen von Dockerfiles finden Sie in der Docker-Dokumentation.

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.

Nachdem Sie den Speicherort angegeben haben, wird eine Zusammenfassung des Triggers angezeigt:

Hinweise

Weitere Informationen

  • 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

Console

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

    Seite "Trigger" aufrufen

  2. Wählen Sie oben auf der Seite im Drop-down-Menü zur Projektauswahl Ihr Projekt aus.

  3. Klicken Sie auf Öffnen.

  4. Klicken Sie auf Trigger erstellen.

  5. Geben Sie die folgenden Triggereinstellungen ein:

    • Name: Geben Sie einen Namen für den Trigger ein.

    • Beschreibung (optional): Geben Sie eine Beschreibung für den Trigger ein.

    • Ereignis: Wählen Sie das Repository-Ereignis aus, das den Trigger auslösen soll.

      • Push zu Zweig: Legen Sie den Trigger so fest, dass ein Build für Commits zu einem bestimmten Zweig gestartet wird.

      • Neues Tag mit Push übertragen: Legen Sie den Trigger so fest, dass ein Build für Commits gestartet wird, die ein bestimmtes Tag enthalten.

    • Quelle: Wählen Sie das Repository und den entsprechenden Zweig oder das entsprechende Tag aus, um es auf Ereignisse zu prüfen.

      • Repository: Wählen Sie aus der Liste der verfügbaren Repositories das gewünschte Repository aus. Informationen zum Verbinden eines neuen Repositories finden Sie unter Verbindung zu Quell-Repositories herstellen.

      Wenn Ihr Build ausgeführt wird, wird der Inhalt Ihres Repositorys in /workspace kopiert, das Standardarbeitsverzeichnis von Cloud Build. Weitere Informationen zu Arbeitsverzeichnissen finden Sie auf der Seite Build-Konfiguration – Übersicht.

      • Zweig oder Tag: Geben Sie einen regulären Ausdruck mit dem abzugleichenden Zweig- oder Tag-Wert an. Schrägstriche (/) können nicht in Tags verwendet werden. Weitere Informationen zur zulässigen Syntax für reguläre Ausdrücke finden Sie unter RE2-Syntax.

    • Konfiguration: Wählen Sie die Build-Konfigurationsdatei aus, die sich in Ihrem Remote-Repository befindet, oder erstellen Sie eine Inline-Build-Konfigurationsdatei für den Build.

      • Typ: Wählen Sie den Konfigurationstyp aus, der für Ihren Build verwendet werden soll.
        • Cloud Build-Konfigurationsdatei (YAML oder JSON): Verwenden Sie eine Build-Konfigurationsdatei für Ihre Konfiguration.
        • Dockerfile: Verwenden Sie für Ihre Konfiguration eine Dockerfile.
        • Buildpacks: Verwenden Sie Buildpacks für Ihre Konfiguration.

      • Speicherort: Geben Sie den Speicherort für Ihre Konfiguration an.

        • Repository: Wenn sich die Konfigurationsdatei in Ihrem Remote-Repository befindet, geben Sie den Speicherort der Build-Konfigurationsdatei, des Verzeichnisses Dockerfile oder des Verzeichnisses „buildpacks“ an. Wenn Ihr Build-Konfigurationstyp eine Dockerfile oder ein Buildpack ist, müssen Sie einen Namen für das resultierende Image und optional ein Zeitlimit für den Build angeben. Wenn Sie den Image-Namen der Dockerfile oder des Buildpacks angegeben haben, sehen Sie eine Vorschau des Befehls docker build oder pack, den Ihr Build ausführen wird.
        • Buildpack-Umgebungsvariablen (Optional): Wenn Sie buildpacks als Konfigurationstyp ausgewählt haben, klicken Sie auf Pack-Umgebungsvariable hinzufügen, um Ihre Buildpack-Umgebungsvariablen und -werte anzugeben. Weitere Informationen zu Buildpack-Umgebungsvariablen finden Sie unter Umgebungsvariablen.

        • Inline: Wenn Sie die Cloud Build-Konfigurationsdatei (YAML oder JSON) als Konfigurationsoption ausgewählt haben, können Sie die Build-Konfiguration inline angeben. Klicken Sie auf Editor öffnen, um Ihre Build-Konfigurationsdatei in der Google Cloud Console mit der YAML- oder JSON-Syntax zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.

    • Dienstkonto: Wählen Sie das Dienstkonto aus, das beim Aufrufen des Triggers verwendet werden soll. Wenn Sie kein Dienstkonto auswählen, wird das Cloud Build-Standarddienstkonto verwendet.

  6. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

gcloud

Führen Sie dazu diesen Befehl aus:

    gcloud beta builds triggers create cloud-source-repositories \
    --repo=REPO_NAME \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --service-account=SERVICE_ACCOUNT \
    --require-approval

Wobei:

  • REPO_NAME ist der Name Ihres Repositorys.
  • BRANCH_PATTERN ist der Zweigname in Ihrem Repository, für den der Build aufgerufen werden soll.
  • TAG_PATTERN ist der Tag-Name in Ihrem Repository, in dem der Build ausgelöst werden soll.
  • BUILD_CONFIG_FILE ist der Pfad zu Ihrer Build-Konfigurationsdatei.
  • SERVICE_ACCOUNT (Vorschau) ist die mit Ihrem Dienstkonto verknüpfte E-Mail-Adresse. Wenn Sie dieses Flag nicht angeben, wird das Standard-Cloud Build-Dienstkonto verwendet.
  • [Optional] --require-approval ist das Flag, das konfiguriert werden soll, um den Trigger so zu konfigurieren, dass er erforderlich ist.

Eine vollständige Liste der Flags finden Sie unter gcloud-Referenz zur Erstellung von Triggern für Cloud Source Repositories.

Nachdem Sie den gcloud-Befehl zum Erstellen eines Triggers mit Cloud Source Repositories ausgeführt haben, sollte eine Ausgabe ähnlich der folgenden angezeigt werden:

  NAME         CREATE_TIME                STATUS
  trigger-001  2019-10-30T20:45:03+00:00

Build-Trigger aufrufen

Öffnen Sie die Cloud Build-Seite Trigger, um die Trigger in der Google Cloud Console anzusehen.

Zum Aufrufen von Triggern für ein bestimmtes Projekt in Cloud Source Repositories klicken Sie rechts oben auf Einstellungen und dann auf Cloud Build-Trigger.

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.

Nächste Schritte