Mit Cloud Build können Sie Trigger erstellen, um Builds aus Repositories auszuführen, die auf Bitbucket Server gehostet werden. So können Sie Builds als Reaktion auf Ereignisse wie Commit-Pushes oder Pull-Anfragen ausführen, die mit Ihrem Bitbucket Server-Repository verknüpft sind.
Auf dieser Seite wird erläutert, wie Sie die Triggerfunktion auf einer Bitbucket Server-Instanz aktivieren.
Hinweise
-
Enable the Cloud Build, Secret Manager, and Compute Engine APIs.
- Wenn Sie noch keine Bitbucket-Serverinstanz installiert haben, finden Sie in der Installationsanleitung für Bitbucket eine entsprechende Anleitung.
- Folgen Sie der Anleitung zum Verbinden eines Bitbucket-Server-Hosts.
- Folgen Sie der Anleitung zum Verbinden eines Bitbucket Server-Repositories.
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 automatisch Builds in Ihren verbundenen Repositories auszuführen. Wenn Sie Bitbucket Server-Trigger in einem privaten Netzwerk verwenden möchten, finden Sie weitere Informationen unter Repositories über Bitbucket Server in einem privaten Netzwerk erstellen.
Console
So erstellen Sie einen Bitbucket Server-Trigger mit der Google Cloud -Console:
Seite "Trigger" aufrufen
Wählen Sie das Projekt oben auf der Seite aus und klicken Sie auf Öffnen.
Klicken Sie auf Trigger erstellen.
Geben Sie die folgenden Triggereinstellungen ein:
Name: Ein Name für Ihren Trigger
Region: Wählen Sie die Region für den Trigger aus.
- Wenn Sie global als Region auswählen, verwendet Cloud Build den Standardpool, um Ihren Build auszuführen.
- Wenn Sie eine nicht globale Region auswählen und in der mit dem Trigger verknüpften Build-Konfigurationsdatei ein privater Pool angegeben ist, verwendet Cloud Build den privaten Pool, um den Build auszuführen. 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 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 den 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 Repositories 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 festlegen, ob für Ereignisse, die keine Kommentare sind, zusätzliche Interaktionen erforderlich sind, um Builds auszulösen. 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 einem Nutzer mit Schreibberechtigungen 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 ein Nutzer mit Schreibberechtigungen
/gcbrun
zur Pull-Anfrage kommentiert hat. SieheCOMMENTS_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 Mitwirkenden erstellt oder aktualisiert wird, werden Builds erst ausgeführt, nachdem ein Inhaber oder ein Nutzer mit Schreibberechtigungen/gcbrun
zu der Pull-Anfrage kommentiert hat. Weitere Informationen finden Sie unterCOMMENTS_ENABLED
.Nicht erforderlich: Wenn eine Pull-Anfrage von einem Mitwirkenden erstellt oder aktualisiert wird, werden Builds automatisch durch Trigger ausgeführt. Weitere Informationen finden Sie unter
COMMENTS_DISABLED
.
Zu den nicht kommentierenden Ereignissen in Bitbucket Server gehören Aktionen wie das Öffnen, Ändern und Genehmigen von Pull-Anfragen.
Kommentarereignisse, z. B. das Hinzufügen, Bearbeiten und Löschen von Kommentaren, lösen nur dann Builds aus, wenn der Kommentar von einem Nutzer mit Schreibberechtigung oder höher stammt und
/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 den 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 Ihrer Build-Konfigurationsdatei oder des
Dockerfile
-Verzeichnisses und einen Namen für das resultierende Image an. Wenn Ihre Konfiguration eineDockerfile
ist, können Sie optional ein Zeitlimit für Ihren Build angeben. Wenn SieDockerfile
und den Image-Namen angegeben haben, sehen Sie eine Vorschau des Befehlsdocker 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.
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 die Groß-/Kleinschreibung berücksichtigt.
- 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 mit Ihrer Bitbucket Server-Konfiguration verknüpft ist.
- ID ist die ID Ihrer BitbucketServerConfig.
- BRANCH_NAME ist ein regulärer Ausdruck, der mit Ihrem Zweig übereinstimmt, wenn Sie den Trigger so einrichten möchten, dass bestimmte Zweige erstellt werden.
- TAG_NAME ist ein regulärer Ausdruck, der mit Ihrem Tag übereinstimmt, wenn Sie den Trigger so einrichten möchten, dass bestimmte Tags erstellt werden.
- 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 die Groß-/Kleinschreibung berücksichtigt.
- BRANCH_NAME ist der reguläre Ausdruck Ihres Zweigs, wenn Sie den Trigger so einstellen möchten, dass bestimmte Zweige erstellt werden.
- TAG_NAME ist der reguläre Ausdruck Ihres Tags, wenn Sie den Trigger so einrichten möchten, dass bestimmte Tags erstellt werden.
- PROJECT_NUMBER ist die Projektnummer Ihres Cloud-Projekts.
- REGION ist die Region, die mit Ihrer Bitbucket Server-Konfiguration verknüpft ist.
- ID ist die ID Ihrer BitbucketServerConfig.
- Mit COMMENT_SETTING können Sie festlegen, 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 Projektnummer Ihres Google Cloud -Projekts.
- PROJECT_ID ist die Projekt-ID Ihres Google Cloud -Kontos.
Datenfreigabe
Anhand der Daten, die von Cloud Build an Bitbucket Server gesendet werden, können Sie Trigger nach Namen erkennen und Build-Ergebnisse in Bitbucket Server aufrufen.
Die folgenden Daten werden zwischen Cloud Build und Bitbucket Server geteilt:
- Google Cloud Projekt-ID
- Triggername
Die Datenfreigabe ist für Bitbucket Server automatisch aktiviert.
Nächste Schritte
- Weitere Informationen finden Sie unter Build-Trigger erstellen und verwalten.
- Weitere Informationen zum Erstellen von Repositories über Bitbucket Server in einem privaten Netzwerk
- Weitere Informationen zu Blau/Grün-Bereitstellungen in der Compute Engine