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 keine Bitbucket Server-Instanz installiert haben, lesen Sie die Installationsanleitung.
- Folgen Sie der Anleitung zum Verbinden eines Bitbucket-Server-Hosts.
- Folgen Sie der Anleitung, um ein Bitbucket Server-Repository zu verbinden.
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 aus 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 als Region global auswählen, Cloud Build verwendet die Standardeinstellung zur Ausführung Ihres Builds.
- 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 im Trigger angegebene Region mit der Region übereinstimmen, in der Sie den 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 Eigentümer und Mitbearbeiter: Bei einem Pull-Vorgang Die Anfrage wird von einem Repository-Inhaber oder einem Nutzer erstellt oder aktualisiert mit Schreibberechtigungen, werden Builds automatisch von den Trigger. 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. Weitere Informationen finden Sie unterCOMMENTS_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 die von anderen Beitragenden erstellt oder aktualisiert wurden, ausgeführt nach einem Kommentar durch einen Inhaber oder einen Nutzer mit Schreibberechtigungen/gcbrun
für die Pull-Anfrage. 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
.
In Bitbucket Server umfassen Ereignisse ohne Kommentar unter anderem folgende Aktionen: Pull-Anfragen öffnen, ändern und genehmigen.
Kommentarereignisse, z. B. Hinzufügen, Bearbeiten und Löschen Kommentare werden nur dann Builds ausgelöst, wenn der Kommentar von einem Nutzer mit Schreibberechtigungen oder höher haben und der Kommentar
/gcbrun
enthält.Weitere Informationen zu Bitbucket Server-Ereignistypen finden Sie unter Bitbucket Dokumentation zum Verwalten von Webhooks
Konfiguration: Wählen Sie die Build-Konfigurationsdatei aus, die sich im Ihr Repository oder konfigurieren Sie Ihren Build inline den 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 der Repository, geben Sie den Speicherort Ihres Build-Konfigurationsdatei oder
Dockerfile
Verzeichnis und einen Namen für das resultierende Image. 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 der Google Cloud Console 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
Um einen Bitbucket Server-Trigger mit gcloud
-Befehlen zu erstellen, führen Sie
müssen Sie Folgendes ausführen:
gcloud builds triggers create bitbucketserver
-Befehl in
Ihrem Terminal:
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 unter Bitbucket-Leitfaden zu Repository-Slugs.
- PROJECT_NUMBER ist die Projektnummer Ihres Cloud-Projekts.
- REGION ist die Region, die Ihrer Bitbucket-Serverkonfiguration zugeordnet 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 unter 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 so einstellen möchten, dass bestimmte Zweige erstellt werden.
- TAG_NAME ist der reguläre Ausdruck Ihres Tags, wenn Sie um bestimmte Tags zu erstellen.
- 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 der Einstellung COMMENT_SETTING wird gesteuert, ob für Build-Trigger
/gcbrun
in einem Kommentar erforderlich ist, damit der Build ausgeführt werden kann. Weitere Informationen finden Sie unter commentControl.
Geben Sie den folgenden curl
-Befehl in Ihrem 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 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 von Cloud Build und Bitbucket Server gemeinsam verwendet:
- 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