Repositories aus GitHub erstellen

Mit GitHub-Triggern können Sie automatisch auf Git-Push- und Pull-Anfragen zugreifen und Ihre Build-Ergebnisse auf GitHub und der Konsole aufrufen. Außerdem unterstützen GitHub-Trigger alle Funktionen, die von vorhandenen GitHub-Triggern unterstützt werden, und verwenden die Cloud Build-GitHub-Anwendung, um GitHub zu konfigurieren und zu authentifizieren.

Auf dieser Seite wird erläutert, wie Sie mit der Cloud Build GitHub-App GitHub-Trigger erstellen und auf GitHub entwickeln.

Hinweis

  • Cloud Build API aktivieren.

    Aktivieren Sie die API

GitHub-Trigger erstellen

Console

So erstellen Sie GitHub-Trigger mit der Google Cloud 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.

    • Region: Wählen Sie die Region für den Trigger aus.

      • Wenn Sie global als Region auswählen, verwendet Cloud Build den Standardpool zum Ausführen des Builds.
      • Wenn Sie eine nicht globale Region auswählen und die mit dem Trigger verknüpfte Build-Konfigurationsdatei einen privaten Pool angibt, verwendet Cloud Build den privaten Pool, um den Build auszuführen. In diesem Fall muss die Region, die Sie im Trigger angeben, mit der Region übereinstimmen, in der Sie den privaten Pool erstellt haben.
      • Wenn Sie eine nicht globale Region auswählen und die mit dem Trigger verknüpfte Build-Konfigurationsdatei keinen privaten Pool angibt, verwendet Cloud Build den Standardpool, um Ihren Build in derselben Region wie Ihren Trigger auszuführen.
    • 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.

      • Pull-Anfrage (Cloud Source Repositories wird nicht unterstützt): Legen Sie Ihren Trigger fest, um einen Build-Commit an eine Pull-Anfrage zu starten.

    • 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 Zusätzliche Repositories verbinden.

      • Zweig oder Tag: Geben Sie einen regulären Ausdruck mit dem abzugleichenden Zweig- oder Tag-Wert an. Informationen zur zulässigen Syntax für reguläre Ausdrücke finden Sie unter RE2-Syntax.

      • Kommentarsteuerung: Wenn Sie Pull-Anfrage (nur GitHub-App) als Ereignis ausgewählt haben, wählen Sie eine der folgenden Optionen aus, um zu kontrollieren, ob ein Build automatisch vom Trigger ausgeführt wird:

        • Erforderlich, außer für Inhaber und Mitbearbeiter: Wenn eine Pull-Anfrage von einem Repository-Inhaber oder Mitbearbeiter erstellt oder aktualisiert wird, werden Builds automatisch vom Trigger ausgeführt. Wenn ein externer Mitwirkender die Aktion initiiert, werden Builds nur ausgeführt, nachdem ein Inhaber oder Mitbearbeiter /gcbrun zur Pull-Anfrage kommentiert hat.

        • Erforderlich: Wenn eine Pull-Anfrage von einem Mitwirkenden erstellt oder aktualisiert wird, werden Builds erst ausgeführt, nachdem ein Inhaber oder Mitbearbeiter /gcbrun zu der Pull-Anfrage kommentiert hat. Builds werden bei jeder Änderung einer Pull-Anfrage ausgeführt.

        • Nicht erforderlich: Wenn eine Pull-Anfrage von einem Mitwirkenden erstellt oder aktualisiert wird, werden Builds automatisch durch Trigger ausgeführt.

    • Enthaltene Dateien (optional): Änderungen, die mindestens eine dieser Dateien betreffen, lösen einen Build aus.

    • Ignorierte Dateien (optional): Änderungen, die sich nur auf die ignorierten Dateien beziehen, lösen keinen Build aus.

    • 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.
      • Speicherort: Geben Sie den Speicherort für Ihre Konfiguration an.

        • Repository: Wenn sich die Konfigurationsdatei in Ihrem Remote-Repository befindet, geben Sie den Speicherort Ihrer Build-Konfigurationsdatei oder des Dockerfile-Verzeichnisses und einen Namen für das resultierende Image an. Wenn Ihre Konfiguration eine Dockerfile ist, können Sie optional ein Zeitlimit für Ihren Build angeben. Wenn Sie Dockerfile und den Image-Namen angegeben haben, sehen Sie eine Vorschau des Befehls docker build, den Ihr Build ausführen wird.
        • 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 YAML- oder JSON-Syntax zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.
  6. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

Informationen zum Erstellen von GitHub-Triggern mit gcloud-Befehlen finden Sie in den gcloud-Befehlen zum Erstellen eines Build-Triggers.

gcloud

Führen Sie den folgenden Befehl aus, um GitHub-Trigger mit gcloud-Befehlen zu erstellen:

gcloud beta builds triggers create github \
    --repo-name=REPO_NAME \
    --repo-owner=REPO_OWNER \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --include-logs-with-status

Dabei gilt:

  • REPO_NAME ist der Name Ihres Repositorys.
  • REPO_OWNER ist der Nutzername des Repository-Inhabers.
  • 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.
  • [OPTIONAL] --include-logs-with-status ist ein Flag, das Sie angeben können, um Build-Logs für Ihre Repositories anzuzeigen. Dieses Flag wird für Builds aus GitHub- und GitHub Enterprise-Repositories unterstützt. Informationen zum Aufrufen von Build-Logs finden Sie unter Build-Logs aufrufen.

Änderungen erstellen und ansehen

Um Builds mit GitHub-Triggern zu erstellen, müssen Sie ein Commit der Änderungen an Ihr verbundenes Quell-Repository übertragen oder Ihren Build für Pull-Anfragen konfigurieren. Nachdem Sie Ihre Änderungen geprüft haben, erstellt Cloud Build Ihren Code.

Rufen Sie den Tab „Prüfungen“ in Ihrem Repository auf, um Ihre Build-Änderungen auf GitHub einzusehen.

Screenshot des Tabs "Conversation"

Sie werden feststellen, dass Cloud Build Ihre Änderungen erstellt hat. Andere Build-Details wie die Zeit, die für die Erstellung Ihres Codes benötigt wurde, die Build-ID usw. werden ebenfalls angezeigt.

Klicken Sie auf Weitere Details in Google Cloud Build anzeigen, um Ihre Build-Änderungen in Cloud Build anzusehen. Die Seite Build-Details in der Konsole wird geöffnet. Dort finden Sie Build-Informationen wie Status, Logs und Build-Schritte.

Verschiedene Typen von GitHub-basierten Triggern

Wenn sich Ihr Quellcode in GitHub befindet, bietet Cloud Build zwei Möglichkeiten zum automatischen Ausführen Ihrer Builds. In diesem Abschnitt werden die beiden auf GitHub basierenden Trigger erläutert und deren Funktionen verglichen.

  • GitHub-Legacy-Trigger: Wenn Sie einen GitHub-Legacy-Trigger erstellen, wird Ihr GitHub-Repository von Cloud Build in Cloud Source Repositories gespiegelt und dieses gespiegelte Repository für alle Vorgänge verwendet. Sie können GitHub-Trigger in der Konsole erstellen und verwalten

  • GitHub-Trigger: Dieser Triggertyp verwendet die Cloud Build-GitHub-App zur Konfiguration und Authentifizierung bei GitHub. Mit GitHub-Triggern können Sie Builds automatisch für Git-Push- und Pull-Anfragen starten und Build-Ergebnisse auf GitHub und in der Console aufrufen. Sie können GitHub-Trigger mithilfe der Konsole oder der Cloud Build API wie auf dieser Seite beschrieben erstellen und verwalten.

  • GitHub Enterprise-Trigger: Mit dieser Art von Trigger können Sie Builds als Reaktion auf Commits oder Pull-Anfragen auf einer GitHub Enterprise-Instanz aufrufen. Sie können Repositories über GitHub Enterprise über die Konsole oder die Cloud Build API erstellen.

In der folgenden Tabelle werden Legacy-GitHub-, GitHub- und GitHub Enterprise-Trigger verglichen:

Feature GitHub-Legacy-Trigger GitHub-Trigger GitHub Enterprise-Trigger
Builds für Push-Anfragen an Quellcode ausführen Ja Ja Ja
Builds für Pull-Anfragen ausführen Nein Ja Ja
Trigger mit Konsole erstellen Ja Ja Ja
Erstellung von Triggern über die Cloud Build API Nein Ja Ja
Erstellung von Triggern über die Cloud Build-GitHub-App Nein Ja Ja
Build-Status in der Konsole ansehen Ja Ja Ja
Anzeige des Build-Status auf GitHub Nein Ja Ja

Datenfreigabe

GitHub-Trigger senden Daten an die Cloud Build GitHub-Anwendung. Die an die Anwendung gesendeten Daten unterstützen Sie dabei, Trigger nach Namen zu erkennen und Build-Ergebnisse auf GitHub aufzurufen.

Die folgenden Daten werden derzeit von der Google Cloud und der GitHub-App geteilt:

  • ID des Cloud-Projekts
  • Triggername
  • Build-Logs

Wenn Sie Trigger vor August 2020 erstellt haben, ist die Datenfreigabe für Ihr Projekt möglicherweise nicht aktiviert. Sie können die Datenfreigabe für alle GitHub-Trigger in Ihrem Projekt aktivieren, indem Sie auf dem Tab „Datenfreigabe“ in Cloud Build auf Aktivieren klicken.

Wenn für ein GitHub-Repository erforderliche Statusprüfungen aktiviert sind, kann das Aktivieren der Datenfreigabe vorübergehend die Statusprüfungen beeinträchtigen. Sie können die Konfigurationen für die Statusprüfung so anpassen, dass nach dem Triggernamen gesucht wird:

  • Cloud Build-spezifische erforderliche Prüfungen im GitHub-Repository deaktivieren
  • Datenfreigabe in Cloud Build sicher aktivieren
  • Neuen Build in Cloud Build ausführen, der Status in Ihr Repository überträgt
  • Erforderliche Statusprüfungen wieder aktivieren und Triggername auswählen

Weitere Informationen