Repositories aus GitHub Enterprise erstellen

Mit Cloud Build können Sie Trigger auf einer GitHub Enterprise-Instanz erstellen. Auf dieser Seite wird erläutert, wie Sie mit GitHub Enterprise-Triggern Builds als Reaktion auf Commits oder Pull-Anfragen aus einem GitHub Enterprise-Repository aufrufen.

Weitere Informationen zu Cloud Build-Triggern und Cloud Build-Repositories

Hinweise

  • Cloud Build and Secret Manager APIs aktivieren.

    Aktivieren Sie die APIs

GitHub Enterprise-Trigger erstellen

In diesem Abschnitt wird erläutert, wie Sie einen Trigger erstellen und mit Ihrer GitHub Enterprise-Installation verknüpfen. Wenn Sie GitHub Enterprise-Trigger in einem privaten Netzwerk verwenden möchten, finden Sie weitere Informationen unter Repositories von GitHub Enterprise in einem privaten Netzwerk erstellen.

Console

So erstellen Sie GitHub Enterprise-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 Ihren Trigger aus.

      • Wenn die mit dem Trigger verknüpfte Build-Konfigurationsdatei einen privaten Pool angibt, verwendet Cloud Build den privaten Pool, um Ihren Build auszuführen. In diesem Fall muss die im Trigger angegebene Region mit der Region übereinstimmen, in der Sie Ihren privaten Pool erstellt haben.
      • Wenn in der mit dem Trigger verknüpften Build-Konfigurationsdatei kein privater Pool angegeben ist, verwendet Cloud Build den Standardpool, um den Build in derselben Region wie den 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: Legen Sie den Trigger so fest, dass ein Build für Commits zu einer Pull-Anfrage gestartet wird.

    • Quelle: Wählen Sie 2. Generation als Quelle aus.

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

      • 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 Repository-Inhaber oder Mitbearbeiter mit /gcbrun in der Beschreibung oder im Kommentar der Pull-Anfrage erstellt oder aktualisiert wird, werden Builds automatisch vom Trigger ausgeführt. Wenn eine Pull-Anfrage von einem Beitragenden erstellt oder aktualisiert wird, werden Builds erst ausgeführt, wenn ein Inhaber oder Mitbearbeiter /gcbrun in der Pull-Anfrage kommentiert.

        • 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.
        • Automatisch erkannt: Cloud Build erkennt Ihren Konfigurationstyp automatisch, wenn Ihr Repository cloudbuild.yaml oder Dockerfile enthält.
        • 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 oder das Verzeichnis Dockerfile 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 der YAML- oder JSON-Syntax zu schreiben. Klicken Sie auf Fertig, um die Build-Konfiguration zu speichern.
    • Substitutionsvariablen (optional): Wenn Sie die Cloud Build-Konfigurationsdatei als Build-Konfigurationsoption ausgewählt haben, können Sie triggerspezifische Substitutionsvariablen mithilfe dieses Felds definieren. Beispiel: Sie erstellen mehrere Trigger, bei denen jeder Trigger Ihre Anwendung für eine bestimmte Umgebung bereitstellt. Sie können angeben, dass Ihre Anwendung in einer Umgebung in Ihrer Build-Konfigurationsdatei bereitgestellt wird und dieses Feld verwenden, um Substitutionsvariablen zu definieren, die festlegen, in welcher Umgebung dieser Trigger bereitgestellt werden soll. Informationen zum Angeben von Substitutionswerten in Build-Konfigurationsdateien finden Sie unter Variablenwerte ersetzen.

    • Build-Logs (optional): Klicken Sie das Kästchen an, um Build-Logs an GitHub zu senden. Informationen zum Aufrufen von Build-Logs finden Sie unter Build-Logs ansehen.

    • 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.

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 Enterprise-Trigger mit gcloud-Befehlen zu erstellen:

gcloud builds triggers create github \
  --name=TRIGGER_NAME \
  --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
  --branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN \
  --build-config=BUILD_CONFIG_FILE \
  --region=REGION

Wobei:

  • TRIGGER_NAME ist der Name des Triggers.
  • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
  • REGION ist die Region für Ihren Trigger.
  • CONNECTION_NAME ist der Name Ihrer GitHub Enterprise-Verbindung.
  • 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.

Datenfreigabe

Anhand der von Cloud Build an GitHub Enterprise gesendeten Daten können Sie Trigger anhand des Namens identifizieren und Build-Ergebnisse auf GitHub Enterprise ansehen.

Die folgenden Daten werden derzeit zwischen Cloud Build und GitHub Enterprise freigegeben:

  • 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 Enterprise-Trigger in Ihrem Projekt aktivieren. Klicken Sie dazu auf dem Tab „Cloud Build-Datenfreigabe“ auf Aktivieren.

Wenn Sie für ein GitHub Enterprise-Repository erforderliche Statusprüfungen aktiviert haben, kann durch das Aktivieren der Datenfreigabe die Statusprüfung vorübergehend unterbrochen werden. 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 Enterprise-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

Nächste Schritte