Repositories von GitLab erstellen

Auf dieser Seite wird erläutert, wie Sie mithilfe von Webhook-Triggern GitLab erstellen.

Hinweis

  • Cloud Build and Secret Manager APIs aktivieren.

    Aktivieren Sie die APIs

  • Wenn Sie gcloud-Befehle auf dieser Seite verwenden möchten, installieren Sie das Cloud SDK.

Einrichten

Bevor Sie einen Webhook-Trigger für GitLab erstellen, müssen Sie einen SSH-Schlüssel erstellen, um die Verbindung zu GitLab zu authentifizieren. Wenn Sie einen Trigger ohne verknüpftes Repository erstellen und auf Ihren Code in einem externen Quellcodeverwaltungssystem wie GitLab zugreifen, müssen Sie den SSH-Schlüssel in der Inline-Build-Konfiguration abrufen.

In diesem Abschnitt wird erläutert, wie Sie Ihren SSH-Schlüssel erstellen und speichern, bevor Sie einen Webhook-Trigger erstellen.

SSH-Schlüssel erstellen

Für den Zugriff auf den Code in GitLab müssen Sie einen SSH-Schlüssel in der Inline-Build-Konfiguration abrufen.

So erstellen Sie einen SSH-Schlüssel:

  1. Öffnen Sie ein Terminalfenster.

  2. Erstellen Sie ein neues Verzeichnis mit dem Namen working-dir und rufen Sie dieses Verzeichnis auf:

    mkdir working-dir
    cd working-dir
    
  3. Erstellen Sie einen neuen GitLab-SSH-Schlüssel, wobei gitlab.com die URL für Ihr GitLab-Repository ist:

    ssh-keygen -t rsa -b 4096 -N '' -C gitlab.com -f id_gitlab
    

    Der Befehl erstellt in working-dir/id_gitlab einen neuen SSH-Schlüssel ohne Passphrase für den SSH-Schlüssel. Cloud Build kann nicht Ihren SSH-Schlüssel verwenden, wenn er mit einer Passphrase geschützt ist.

SSH-Zugriff in GitLab aktivieren

Sie müssen den SSH-Zugriff auf Ihrem GitLab aktivieren, damit Nutzer auf Ihrem Server ihre eigenen SSH-Schlüssel hinzufügen und diese SSH-Schlüssel verwenden können, um Git-Vorgänge zwischen ihrem Computer und der GitLab-Instanz zu sichern. Informationen zur Verwendung von SSH mit GitLab finden Sie unter GitLab und SSH-Schlüssel.

Öffentlichen SSH-Zugriffsschlüssel in GitLab hinzufügen

Zum Schutz der Vorgänge, die andere Systeme in den in GitLab verwalteten Repositories ausführen, müssen Sie den öffentlichen SSH-Zugriffsschlüssel zu GitLab hinzufügen. Weitere Informationen zum Hinzufügen eines Schlüssels finden Sie unter SSH-Schlüssel zu GitLab-Konto hinzufügen.

Anmeldedaten in Secret Manager erstellen und speichern

Wenn Sie einen SSH-Schlüssel erstellen, wird in Ihrer lokalen Umgebung die Datei id_gitlab erstellt. Da diese Datei vertrauliche Informationen zur Authentifizierung enthält, müssen Sie sie in Secret Manager speichern, bevor Sie sie zum Aufrufen eines Builds verwenden.

Zusätzlich zum Secret, das beim Erstellen eines Webhook-Triggers verwendet wird, müssen Sie in Secret Manager auch ein Secret erstellen, um eingehende Webhook-Ereignisse zu validieren und in Cloud Build zu autorisieren.

So erstellen und speichern Sie Ihre Anmeldedaten in Secret Manager:

  1. Rufen Sie in der Cloud Console die Seite "Secret Manager" auf:

    Zur Seite "Secret Manager"

  2. Klicken Sie auf der Seite Secret Manager auf Secret erstellen.

  3. Geben Sie auf der Seite Secret erstellen unter Name einen Namen für das Secret ein.

  4. Geben Sie im Feld Secret-Wert einen Namen für das Secret ein oder laden Sie eine Datei hoch.

    Klicken Sie zum Hochladen der SSH-Schlüsseldatei auf Hochladen und fügen Sie die Datei working-dir/id_gitlab hinzu.

  5. Lassen Sie den Abschnitt Regionen unverändert.

  6. Klicken Sie auf Secret erstellen, um das Secret zu erstellen.

Nachdem Sie das Secret erstellt haben, weist die Google Cloud Console Ihrem Cloud Build-Dienstkonto ${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com automatisch die Rolle Secret Manager-Zugriffsfunktion zu. Wenn diese Rolle in Ihrem Dienstkonto nicht angezeigt wird, führen Sie die folgenden Schritte aus, die unter Secret Manager-Rolle für Ihr Dienstkonto zuweisen beschrieben werden.

Nachdem Sie den SSH-Schlüssel gespeichert haben, können Sie ihn auch mit dem folgenden Befehl aus Ihrer Umgebung löschen:

rm id_gitlab*

Sie können jetzt Ihren Webhook-Trigger erstellen.

Webhook-Trigger erstellen

Console

So erstellen Sie einen Webhook-Trigger, der Builds über GitLab mit der Google Cloud Console aufruft:

  1. Seite "Trigger" aufrufen

    Zur Seite "Build-Trigger"

  2. Wählen Sie das Projekt oben auf der Seite aus und klicken Sie auf Öffnen.

  3. Klicken Sie auf Trigger erstellen.

  4. Geben Sie die folgenden Triggereinstellungen ein:

    • Name: Ein Name für Ihren Trigger
    • Beschreibung Optional: Eine Beschreibung für Ihren Trigger.
    • Ereignis: Wählen Sie Webhook-Ereignis aus, um den Trigger zum Starten von Builds als Reaktion auf eingehende Webhook-Ereignisse einzurichten.
    • Webhook-URL: Authentifizieren Sie eingehende Webhook-Ereignisse mit der Webhook-URL.

      • Secret: Sie benötigen ein Secret zur Authentifizierung eingehender Webhook-Ereignisse. Sie können ein neues Secret erstellen oder ein vorhandenes verwenden.

        So erstellen Sie ein neues Secret:

        1. Wählen Sie Neu erstellen aus.
        2. Klicken Sie auf Secret erstellen.

          Daraufhin wird das Pop-up-Fenster Secret für Webhook erstellen eingeblendet.

        3. Geben Sie im Feld Secret-Name einen Namen für das Secret ein.

        4. Klicken Sie auf Secret erstellen, um Ihr Secret zu speichern. Es wird automatisch in Secret Manager für Sie erstellt und gespeichert.

        So verwenden Sie ein vorhandenes Secret:

        1. Wählen Sie Vorhandene verwenden aus.
        2. Wählen Sie im Feld Secret den Namen des Secrets aus, das Sie verwenden möchten, oder wählen Sie die Anleitung zum Hinzufügen eines Secrets nach Ressourcen-ID aus.
        3. Wählen Sie im Feld Secret-Version Ihre Secret-Version aus dem Drop-down-Menü aus.

        Wenn Sie ein vorhandenes Secret verwenden, müssen Sie dem Cloud Build-Dienstkonto ${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com möglicherweise die Rolle SecretSecret Accessor“ manuell zuweisen. Weitere Informationen finden Sie unter Secret Manager-Rolle für das Dienstkonto zuweisen.

      Nachdem Sie das Secret erstellt oder ausgewählt haben, wird die Vorschau der Webhook-URL angezeigt. Die URL enthält einen API-Schlüssel, der von Cloud Build und Ihrem Secret generiert wird. Sollte Ihr Cloud Build nicht in der Lage sein, Ihren API-Schlüssel abzurufen, können Sie ihn manuell der URL hinzufügen oder lernen, wie Sie einen API-Schlüssel abrufen, wenn Sie keinen haben. noch keine.

      Sie können die URL zum Aufrufen eines Webhook-Ereignisses verwenden. Senden Sie dazu eine HTTP-Anfrage mit der POST-Methode.

       curl -X POST -H "application/json" "https://cloudbuild.googleapis.com/v1/projects/${PROJECT_NAME}/triggers/${TRIGGER_NAME}:webhook?key=${API_KEY}&secret=${SECRET_VALUE}" -d "{}"
      

      Informationen zum Verwenden der URL beim Erstellen eines Webhooks in GitLab finden Sie unter Webhook in GitLab erstellen.

    • Quelle (optional): Das Repository, das bei der Ausführung des Webhook-Triggers erstellt wird. Lassen Sie dieses Feld leer. In diesem Beispiel ist die Build-Konfiguration eine Inline-Build-Konfiguration, sodass keine Quelle benötigt wird.

    • Konfiguration: Erstellen Sie eine Inline-Build-Konfiguration in der Google Cloud Console.

      Im folgenden Beispiel authentifiziert die Inline-Build-Konfiguration Ihre Verbindung zu GitLab mit Ihrem SSH-Schlüssel und greift auf Ihr angegebenes Repository zu. Danach wird das Commit geprüft, das den Webhook aufgerufen hat.

      steps:
      # first, setup SSH:
      # 1- save the SSH key from Secret Manager to a file
      # 2- add the host key to the known_hosts file
      - name: gcr.io/cloud-builders/git
        args:
          - '-c'
          - |
            echo "$$SSHKEY" > /root/.ssh/id_rsa
            chmod 400 /root/.ssh/id_rsa
            ssh-keyscan gitlab.com > /root/.ssh/known_hosts
        entrypoint: bash
        secretEnv:
          - SSHKEY
        volumes:
          - name: ssh
            path: /root/.ssh
      # second, clone the repository
      - name: gcr.io/cloud-builders/git
        args:
          - clone
          - '-n'
          - 'git@gitlab.com/GITLAB_REPO'
          - .
        volumes:
          - name: ssh
            path: /root/.ssh
      # third, checkout the specific commit that invoked this build
      - name: gcr.io/cloud-builders/git
        args:
          - checkout
          - $_TO_SHA
      availableSecrets:
        secretManager:
        - versionName: PATH_TO_SECRET_VERSION
          env: SSHKEY
      

      Wobei:

      • GITLAB_REPO ist der Pfad für Ihr GitLab-Repository.
      • PATH_TO_SECRET_VERSION ist der Pfad zu Ihrer Secret-Version, wie in Secret Manager gespeichert. Dies ist das Secret mit Ihrem SSH-Schlüssel. Beispiel: projects/project-id/secrets/secret-name/versions/1
      • SSHKEY ist der Name der Umgebung, in der in diesem Fall der Pfad zu Ihrem Secret gespeichert wird.
    • Substitutionen (optional): Sie können mit diesem Feld triggerspezifische Substitutionsvariablen definieren.

      In diesem Beispiel nehmen wir an, Sie möchten nach einem bestimmten Zweignamen suchen, der einer Commit-ID zugeordnet ist, und dann in der Build-Definition zu diesem Zweignamen wechseln. Sie können Substitutionsvariablen mit Nutzlastbindungen erstellen, um den Branch-Namen zu erhalten, um diese Daten zu erhalten.

      Geben Sie unten die folgenden Variablen und Werte an:

      Variablenname Variablenwert: 
      _BRANCH $(body.ref)
      _TO_SHA $(body.after)

      Informationen zur Nutzlast, die mit GitLab-Ereignissen verknüpft ist, finden Sie auf der GitLab-Dokumentationsseite unterVeranstaltungen aus.

    • Filter (optional): Sie können in einem Trigger eine Regel erstellen, die festlegt, ob Ihr Trigger einen Build basierend auf den Substitutionsvariablen ausführt.

      Da der Trigger einen Build ausführen soll, wenn der Branch-Name main entspricht, können Sie mit dem Operator "==" nach genauen Übereinstimmungen suchen. Sie können auch das Keyword "stimmt überein mit" verwenden, wenn die Übereinstimmung mit einem regulären Ausdruck erfolgen soll.

      Geben Sie Folgendes als Filter an:

      • _BRANCH == refs/heads/main

      Weitere Beispielsyntax für das Filtern, die Sie auf Ihre Webhook-Trigger anwenden können, finden Sie unter Build-Ereignisse mit CEL filtern.

  5. Klicken Sie auf Erstellen, um den Build-Trigger zu erstellen.

gcloud

So erstellen Sie einen Webhook-Trigger, der Builds von GitLab aufruft:

     gcloud alpha builds triggers create webhook \
       --name=TRIGGER_NAME \
       --repo=PATH_TO_REPO \
       --secret=PATH_TO_SECRET \
       --substitutions=''
       --filter=''
       --inline-config=PATH_TO_INLINE_BUILD_CONFIG
       --branch=BRANCH_NAME # --tag=TAG_NAME

Wobei:

  • TRIGGER_NAME ist der Name des Triggers.
  • PATH_TO_REPO ist der Pfad zum Repository, auf dem ein Build aufgerufen wird. Beispiel: https://www.github.com/owner/repo.
  • PATH_TO_SECRET ist der Pfad zu Ihrem Secret, wie in Secret Manager gespeichert. Beispiel: projects/my-project/secrets/my-secret/versions/2
  • PATH_TO_INLINE_BUILD_CONFIG ist der Pfad zu Ihrer Inline-Build-Konfiguration.

  • BRANCH_NAME ist der Name Ihres Zweigs, wenn Sie den Trigger für einen Zweig festlegen möchten.

  • TAG_NAME ist der Name des Tags, wenn Sie den Trigger für die Erstellung eines Tags festlegen möchten.

Webhook in GitLab erstellen

Damit GitLab Anfragen an Cloud Build senden kann, müssen Sie einen Webhook in GitLab erstellen. Folgen Sie dazu der Anleitung in der GitLab-Dokumentation für Webhooks.

Jedes Mal, wenn Aktualisierungen des Repositorys mit dem Triggerereignis übereinstimmen, das Sie im Webhook angegeben haben, wird der Build automatisch von den Cloud Build-Webhook-Triggern aufgerufen.

Nächste Schritte