Repositories aus GitHub erstellen

Mit Cloud Build können Sie Trigger erstellen, um aus Repositories zu erstellen, die auf GitHub gehostet werden. Sie können Builds als Reaktion auf Ereignisse wie Commit-Pushes oder Merge-Anfragen ausführen, die mit Ihrem GitHub-Repository verknüpft sind.

Auf dieser Seite wird erläutert, wie Sie Build-Trigger für eine GitHub-Instanz aktivieren. Weitere Informationen finden Sie unter Cloud Build-Trigger und Cloud Build-Repositories.

Hinweise

Folgen Sie der Anleitung zum Herstellen einer Verbindung zu einem GitHub-Host.

  • Enable the Cloud Build API.

    Enable the API

Wenn Sie einen Trigger für ein GitHub-Repository erstellen möchten, müssen Sie eine Verbindung zwischen Google Cloud und Ihrem Repository herstellen. Informationen zum Erstellen einer Verbindung über die GitHub-App in Google Cloudfinden Sie unter Verbindung zu einem GitHub-Repository herstellen.

GitHub-Trigger erstellen

In diesem Abschnitt wird erläutert, wie Sie einen Trigger erstellen und mit Ihrer GitHub-Installation verknüpfen.

Google Cloud console

So erstellen Sie GitHub-Trigger mit der Google Cloud Console:

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

    Seite "Trigger" aufrufen

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

  3. Klicken Sie auf Trigger erstellen.

  4. 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 in der Build-Konfigurationsdatei, die dem Trigger zugeordnet ist, ein privater Pool angegeben ist, verwendet Cloud Build den privaten Pool zum Ausführen des Builds. In diesem Fall muss die Region, die Sie in Ihrem Trigger angeben, 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: Konfigurieren Sie Informationen zu Ihrem GitHub-Repository:

      • Repository-Dienst: Wählen Sie Cloud Build aus.

      • Repository-Generierung: Wählen Sie Developer Connect als Quelle aus.

      • Repository: Wählen Sie aus der Liste der verfügbaren Repositories das Repository aus.

      • 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 als Ereignis ausgewählt haben, wählen Sie eine der folgenden Optionen aus, um zu steuern, 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 jedes Mal ausgeführt, wenn eine Änderung an einer Pull-Anfrage vorgenommen wird.

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

    • 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 Sie eine cloudbuild.yaml- oder Dockerfile-Datei in Ihrem Repository haben.
        • 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 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 derGoogle Cloud -Konsole in 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): Aktivieren Sie das Kästchen, um Build-Logs an GitHub zu senden. Informationen zum Ansehen 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 Ihre Organisationsrichtlinie die Verwendung des Legacy-Dienstkontos von Cloud Build zulässt, können Sie dieses Feld leer lassen, um das Legacy-Dienstkonto zu verwenden. Andernfalls müssen Sie das zu verwendende Dienstkonto auswählen, auch wenn es sich um das Compute Engine-Standarddienstkonto handelt.

  5. 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-CLI

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

    gcloud alpha builds triggers create developer connect
      --name=TRIGGER_NAME \
      --git-repository-link=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/gitRepositoryLinks/REPO_NAME \
      --branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN \
      --build-config=BUILD_CONFIG_FILE \
      --region=REGION \
      --service-account=SERVICE-ACCOUNT

Wobei:

  • TRIGGER_NAME ist der Name des Triggers.
  • PROJECT_ID ist die Projekt-ID Ihres Google Cloud .
  • REGION ist die Region Ihres Triggers.
  • CONNECTION_NAME ist der Name Ihrer GitHub-Verbindung.
  • GIT_REPOSITORY_LINK ist der Link zu Ihrem Git-Repository.
  • 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 ist das Dienstkonto, das für Trigger- und Build-Vorgänge verwendet werden soll.

API

So erstellen Sie einen GitHub-Trigger mit der API:

  {
      "filename": "cloudbuild.yaml",
      "name": "TRIGGER_NAME",
      "description": "TRIGGER_DESCRIPTION",
      "serviceAccount": "SERVICE_ACCOUNT",
      "github": {
          "owner": "OWNER",
          "name": "REPO_NAME",
          "push": {
              "branch": ".*"
          },
      
      },
      "include_build_logs": include-build-logs-value
  }

Wobei:

  • TRIGGER_NAME ist ein Name für den Trigger.
  • TRIGGER_DESCRIPTION ist eine Beschreibung für den Trigger.
  • SERVICE_ACCOUNT ist das Dienstkonto, das für Trigger- und Build-Vorgänge verwendet werden soll.
  • OWNER ist der Inhaber des GitHub-Repositorys.
  • REPO_NAME ist der name des GitHub-Repositorys.
  • include-build-logs-value ist der Wert des optionalen Felds include_build_logs. Wenn dieses Feld den Wert INCLUDE_BUILD_LOGS_SPECIFIED hat, werden Build-Logs in Ihrem Repository angezeigt.

Geben Sie den folgenden curl-Befehl in Ihr Terminal ein:

curl -X POST -H "Authorization: Bearer "$(gcloud auth print-access-token) -H "Content-Type: application/json; charset=utf-8" -H "x-goog-user-project: PROJECT_NUMBER" https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/triggers -d @trigger.json

Wobei:

  • PROJECT_NUMBER ist Ihre Google Cloud Projektnummer.
  • PROJECT_ID ist die Projekt-ID Ihres Google Cloud .

Ä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 Google Cloud Console wird geöffnet. Hier können Sie Build-Informationen wie Status, Logs und Build-Schritte einsehen.

Datenfreigabe

Die von Cloud Build an GitHub gesendeten Daten helfen Ihnen, Trigger nach Namen zu identifizieren und Build-Ergebnisse auf GitHub aufzurufen.

Die folgenden Daten werden derzeit von Cloud Build und GitHub 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

Nächste Schritte