Repositories aus Bitbucket Server erstellen

Mit Cloud Build können Sie Trigger für die Erstellung von Builds aus Repositories erstellen, die auf Bitbucket Server gehostet werden. So können Sie Builds als Reaktion auf Ereignisse wie Commit-Push- oder Pull-Anfragen ausführen, die mit Ihrem Bitbucket Server-Repository verknüpft sind.

Auf dieser Seite wird erläutert, wie Sie die Triggerfunktion für eine Bitbucket Server-Instanz aktivieren.

Hinweise

  • Cloud Build, Secret Manager, and Compute Engine APIs aktivieren.

    Aktivieren Sie die APIs

Bitbucket Server-Trigger erstellen

In diesem Abschnitt wird erläutert, wie Sie Ihre Bitbucket Server-Repositories mit Cloud Build verbinden und einen Trigger erstellen, um Builds für Ihre verbundenen Repositories automatisch aufzurufen. Wenn Sie Bitbucket Server-Trigger in einem privaten Netzwerk verwenden möchten, finden Sie weitere Informationen unter Repositories von Bitbucket Server in einem privaten Netzwerk erstellen.

Console

So erstellen Sie einen Bitbucket Server-Trigger mit der Google Cloud Console:

  1. Seite "Trigger" aufrufen

    Seite "Trigger" aufrufen

  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

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

      • Wenn Sie global als Region auswählen, verwendet Cloud Build den Standardpool zum Ausführen Ihres 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 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 Sie eine nicht globale Region auswählen und in der mit dem Trigger verknüpften Build-Konfigurationsdatei kein privater Pool angegeben ist, verwendet Cloud Build den Standardpool, um Ihren Build in derselben Region wie der Trigger auszuführen.
    • Beschreibung Optional: Eine Beschreibung für Ihren Trigger.

    • 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 1. Generation als Quelle aus.

      • Repository: Wählen Sie aus der Liste der verfügbaren Repositories ein Repository aus. Informationen zum Verbinden eines neuen Repositorys finden Sie unter Verbindung zu einem Bitbucket Server-Repository herstellen.

      • Zweig oder Tag: Geben Sie einen regulären Ausdruck mit dem abzugleichenden Zweig- oder Tag-Wert an.

      • Kommentarsteuerung: Wenn Sie Pull-Anfrage als Ereignis ausgewählt haben, können Sie mithilfe von Einstellungen festlegen, ob Ereignisse ohne Kommentar zusätzliche Interaktionen erfordern, um Builds auszulösen. Wählen Sie eine der folgenden Optionen aus, um festzulegen, 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 einem Nutzer mit Schreibberechtigungen erstellt oder aktualisiert wird, werden Builds automatisch vom Trigger ausgeführt. Wenn ein externer Beitragender die Aktion initiiert, werden Builds erst ausgeführt, nachdem ein Inhaber oder ein Nutzer mit Schreibberechtigungen in der Pull-Anfrage /gcbrun kommentiert hat. Siehe COMMENTS_ENABLED_FOR_EXTERNAL_CONTRIBUTORS_ONLY.

        • Erforderlich: Wenn ein Nutzer mit Schreibberechtigungen eine Pull-Anfrage erstellt und /gcbrun in die Beschreibung der Pull-Anfrage einfügt, wird der Build beim Erstellen der Pull-Anfrage ausgeführt. Wenn eine Pull-Anfrage von einem anderen Beitragenden erstellt oder aktualisiert wird, werden Builds erst ausgeführt, nachdem ein Inhaber oder ein Nutzer mit Schreibberechtigungen /gcbrun in der Pull-Anfrage ausgeführt hat. Weitere Informationen finden Sie unter COMMENTS_ENABLED.

        • Nicht erforderlich: Wenn eine Pull-Anfrage von einem Beitragenden erstellt oder aktualisiert wird, werden Builds automatisch durch Trigger ausgeführt. Weitere Informationen finden Sie unter COMMENTS_DISABLED.

        In Bitbucket Server umfassen Ereignisse ohne Kommentar Aktionen wie Öffnen, Ändern und Genehmigen von Pull-Anfragen.

        Kommentarereignisse, darunter das Hinzufügen, Bearbeiten und Löschen von Kommentaren, lösen nur dann Builds aus, wenn der Kommentar von einem Nutzer mit mindestens Schreibberechtigungen stammt und der Kommentar /gcbrun enthält.

        Weitere Informationen zu Bitbucket Server-Ereignistypen finden Sie in der Bitbucket-Dokumentation zum Verwalten von Webhooks.

    • Konfiguration: Wählen Sie die Build-Konfigurationsdatei aus, die sich in Ihrem Repository befindet, oder konfigurieren Sie Ihren Build inline im Trigger.

    • 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 Repository befindet, geben Sie den Speicherort der Build-Konfigurationsdatei oder des Verzeichnisses 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.

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

gcloud

Wenn Sie einen Bitbucket Server-Trigger mit gcloud-Befehlen erstellen möchten, müssen Sie den folgenden gcloud builds triggers create bitbucketserver-Befehl in Ihrem Terminal ausführen:

gcloud builds triggers create bitbucketserver
    --name=TRIGGER_NAME \
    --project-key=PROJECT_KEY \
    --repo-slug=REPO_SLUG \
    --bitbucket-server-config-resource=projects/PROJECT_NUMBER/locations/REGION/bitbucketServerConfigs/ID \
    --branch-pattern=BRANCH_NAME \ # --tag-pattern=TAG_NAME
    --build-config=BUILD_CONFIG

Wobei:

  • TRIGGER_NAME ist der Name des Triggers.
  • PROJECT_KEY ist der Schlüssel Ihres Bitbucket Server-Projekts. Bei PROJECT_KEY wird zwischen Groß- und Kleinschreibung unterschieden.
  • REPO_SLUG ist der Slug Ihres Bitbucket Server-Repositorys. Weitere Informationen finden Sie im Bitbucket-Leitfaden zu Repository-Slugs.
  • PROJECT_NUMBER ist die Projektnummer Ihres Cloud-Projekts.
  • REGION ist die Region, die Ihrer Bitbucket Server-Konfiguration zugeordnet ist.
  • ID ist die ID Ihrer BitbucketServerConfig.
  • BRANCH_NAME ist ein regulärer Ausdruck, der Ihrem Zweig entspricht, wenn Sie den Trigger zum Erstellen bestimmter Zweige einrichten möchten.
  • TAG_NAME ist ein regulärer Ausdruck, der Ihrem Tag entspricht, wenn Sie den Trigger zum Erstellen bestimmter Tags einrichten möchten.
  • BUILD_CONFIG ist der Pfad zu Ihrer Build-Konfigurationsdatei.

API

Verwenden Sie die folgende JSON-Vorlage, um einen Bitbucket Server-Trigger mit der API zu erstellen.

{
    "filename": "cloudbuild.yaml",
    "name": "curl-trigger",
    "description": "curl trigger",
    "bitbucket_server_trigger_config": {
        "repo_slug": "REPO_SLUG",
        "project_key": "PROJECT_KEY",
        "push": {
            "branch": "BRANCH_NAME" # "tag": "TAG_NAME"
        },
        "bitbucket_server_config_resource": "projects/PROJECT_NUMBER/locations/REGION/bitbucketServerConfigs/ID"
        "comment_control": "COMMENT_SETTING"
    }
}

Wobei:

  • REPO_SLUG ist der Slug Ihres Bitbucket Server-Repositorys. Weitere Informationen finden Sie im Bitbucket-Leitfaden zu Repository-Slugs.
  • PROJECT_KEY ist der Schlüssel Ihres Bitbucket Server-Projekts. Bei PROJECT_KEY wird zwischen Groß- und Kleinschreibung unterschieden.
  • BRANCH_NAME ist der reguläre Ausdruck Ihres Zweigs, wenn Sie den Trigger zum Erstellen bestimmter Zweige einrichten möchten.
  • TAG_NAME ist der reguläre Ausdruck Ihres Tags, wenn Sie den Trigger zum Erstellen bestimmter Tags konfigurieren möchten.
  • PROJECT_NUMBER ist die Projektnummer Ihres Cloud-Projekts.
  • REGION ist die Region, die Ihrer Bitbucket Server-Konfiguration zugeordnet ist.
  • ID ist die ID Ihrer BitbucketServerConfig.
  • COMMENT_SETTING ist die Einstellung, mit der festgelegt wird, ob Build-Trigger /gcbrun in einem Kommentar erfordern, damit der Build ausgeführt wird. Weitere Informationen finden Sie unter commentControl.

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 die Nummer Ihres Google Cloud-Projekts.
  • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.

Datenfreigabe

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

Die folgenden Daten werden zwischen Cloud Build und Bitbucket Server geteilt:

  • Google Cloud-Projekt-ID
  • Triggername

Die Datenfreigabe wird für Bitbucket Server automatisch aktiviert.

Nächste Schritte