Cloud Build-Trigger

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu aktivieren. Sie können Trigger konfigurieren, um eingehende Ereignisse zu überwachen, z. B. wenn ein neuer Commit an ein Repository übertragen oder eine Pull-Anfrage initiiert wird, und dann automatisch einen Build ausführen, wenn neue Ereignisse eingehen. Sie können Trigger auch so konfigurieren, dass sie Code bei Änderungen am Quell-Repository oder nur bei Änderungen erstellen, die bestimmte Kriterien erfüllen.

Auf dieser Seite erhalten Sie einen Überblick über die einzelnen Triggertypen und Funktionen, die mit Triggern verknüpft sind.

Trigger für Repository-Ereignisse

Mit Cloud Build können Sie Builds für Repository-Ereignisse wie Push- oder Pull-Anfragen automatisch ausführen. Sie können externe Repositories wie Repositories in GitHub oder Bitbucket mit Cloud Build verbinden oder in Cloud Source Repositories Code für Ihre Builds verwenden. Sie können jedes Quell-Repository mit Cloud Build verbinden. Cloud Build bietet jedoch bestimmte Repository-Ereignis-Trigger, mit denen Sie bestimmte Quellcode-Verwaltungssysteme (SCMs) einbinden können. In diesem Abschnitt werden die verfügbaren Repository-Ereignis-Trigger beschrieben.

GitHub-Trigger

Sie können GitHub-Trigger erstellen, um Builds automatisch als Reaktion auf Repository-Ereignisse wie Push- oder Pull-Anfragen auszuführen. Sie können den Build-Status des Triggers in GitHub und in der Google Cloud Console ansehen. Sie können auch die GitHub-Anwendung „Cloud Build“ verwenden, um eine Verbindung zu GitHub herzustellen und Code in GitHub zu erstellen. Weitere Informationen finden Sie unter Repositories von GitHub erstellen.

GitHub Enterprise-Trigger

Sie können Trigger für Repositories erstellen, die auf einer GitHub Enterprise-Instanz gehostet werden, einschließlich Instanzen, die in einer lokalen Umgebung gehostet und nicht über eine öffentliche Internetverbindung erreichbar sind. GitHub Enterprise-Trigger können zum Ausführen von Builds als Reaktion auf Push- oder Pull-Anfragen von einer GitHub Enterprise-Instanz verwendet werden. Weitere Informationen finden Sie unter Repositories aus GitHub Enterprise erstellen.

GitLab Enterprise Edition-Trigger

Sie können Trigger für Repositories erstellen, die auf einer GitLab Enterprise Edition-Instanz gehostet werden, einschließlich Instanzen, die in einem privaten Netzwerk gehostet werden. Mit GitLab Enterprise Edition-Triggern können Builds als Reaktion auf Commit-Pushes oder Pull-Anfragen ausgeführt werden, die mit Ihrem GitLab Enterprise Edition-Repository verknüpft sind. Weitere Informationen finden Sie unter Repositories aus der GitLab Enterprise Edition erstellen.

Bitbucket Server-Trigger

Sie können Trigger für Repositories erstellen, die auf einer Bitbucket Server-Instanz gehostet werden, einschließlich Instanzen, die in einer lokalen Umgebung gehostet werden. Sie können Ihr Bitbucket Server-Repository mit mehreren Hostverbindungen mehrmals mit Cloud Build verbinden. Weitere Informationen zum Erstellen von Triggern, mit denen Builds als Reaktion auf Ereignisse ausgeführt werden, finden Sie unter Repositories über Bitbucket Server erstellen.

Bitbucket Data Center-Trigger

Sie können Trigger für Repositories erstellen, die auf einer Bitbucket-Rechenzentrums-Instanz gehostet werden, einschließlich Instanzen, die in einer lokalen Umgebung gehostet werden. Mit Bitbucket-Rechenzentrum-Triggern können Builds als Reaktion auf Ereignisse wie Commit-Pushes oder Pull-Anfragen ausgeführt werden. Weitere Informationen finden Sie unter Repositories über Bitbucket Data Center erstellen.

Bitbucket Cloud-Trigger

Sie können Trigger für Repositories erstellen, die in Bitbucket Cloud gehostet werden. Mit Bitbucket Cloud-Triggern können Builds als Reaktion auf Ereignisse wie Commit-Pushes oder Pull-Anfragen ausgeführt werden. Weitere Informationen finden Sie unter Repositories aus Bitbucket Cloud erstellen.

Manuelle Trigger

Sie können manuelle Trigger erstellen, um Builds manuell auszuführen und definierte Werte von Substitutionsvariablen zum Zeitpunkt des Aufrufs vor der Ausführung eines Builds zu überschreiben. Sie können auch manuelle Trigger für die Ausführung nach einem Zeitplan konfigurieren. Weitere Informationen finden Sie unter Code in Quellcode-Repositories manuell erstellen.

Pub/Sub-Trigger

Sie können Pub/Sub-Trigger erstellen, um Builds als Reaktion auf jede über Pub/Sub veröffentlichte Nachricht auszuführen. Sie können beispielsweise Pub/Sub-Trigger zum Erstellen von Antworten als Reaktion auf Image-Push-Vorgänge in Artifact Registry verwenden. In diesem Fall können Sie den Trigger so konfigurieren, dass Filter verwendet werden, um einen Build nur dann auszuführen, wenn das Push-Image mit einem bestimmten Tag wie prod übereinstimmt. Darüber hinaus können Pub/Sub-Trigger so konfiguriert werden, dass sie jedes Pub/Sub-Thema abonnieren. Weitere Informationen finden Sie unter Builds als Reaktion auf Pub/Sub-Ereignisse automatisieren.

Webhook-Trigger

Sie können Webhook-Trigger erstellen, um Builds als Reaktion auf Webhooks auszuführen. Mit Webhook-Ereignissen, die an eine benutzerdefinierte URL gesendet werden, können Sie externe Systeme und externe Quellcodeverwaltungssysteme (SCMs) wie Bitbucket.com, Bitbucket Server oder GitLab direkt mit Cloud Build verbinden. Beim Erstellen von Webhook-Triggern können Sie Ihre Build-Konfiguration auch inline auf Ihrem Trigger definieren, um zu steuern, welche Repositories Ihr Trigger während der Build-Dauer klont, anstatt eine Quelle explizit anzugeben. Weitere Informationen finden Sie unter Builds als Reaktion auf Webhook-Ereignisse automatisieren. Außerdem erfahren Sie, wie Sie mit Webhook-Triggern Repositories aus bestimmten SCMs erstellen. Weitere Informationen finden Sie unter Repositories über Bitbucket Server erstellen, Repositories aus Bitbucket Cloud erstellen und Repositories aus GitLab erstellen.

Triggerfunktionen

Cloud Build-Trigger bieten Funktionen, mit denen Sie die Ausführung eines Builds genau steuern können. In diesem Abschnitt werden verschiedene Funktionen für Trigger erläutert.

Geplante manuelle Trigger

Sie können manuelle Trigger planen, um Builds automatisch nach einem vordefinierten Zeitplan auszuführen. Sie können beispielsweise einen geplanten Trigger konfigurieren, um einen Build jeden Samstag um 6:00 Uhr auszuführen. Zum Planen von Builds können Sie einen manuellen Trigger erstellen und den Trigger mit Cloud Scheduler aufrufen. Weitere Informationen finden Sie unter Builds planen.

Ereignisse filtern

Cloud Build verwendet CEL (Common Expression Language) mit der Variablen build für Felder in der Ressource Build, um auf Felder zuzugreifen, die mit Ihrem Build-Ereignis verknüpft sind, z. B. Ihre Trigger-ID, Image-Liste oder Ersatzwerte. Sie können den String filter verwenden, um Build-Ereignisse in Ihrer Build-Konfigurationsdatei mit einem Feld zu filtern, das in der Ressource Build aufgeführt ist. Weitere Informationen finden Sie unter Build-Ereignisse mit CEL filtern.

Substitutionsvariablen

Sie können in der Build-Konfigurationsdatei Substitutionsvariablen angeben, um bestimmte Werte zum Build-Zeitpunkt zu ersetzen. Sie können beispielsweise Substitutionsvariablen verwenden, wenn ein Wert bis zur Erstellung des Builds nicht bekannt ist oder wenn Sie eine vorhandene Build-Anfrage mit anderen Variablen wiederverwenden möchten. Cloud Build bietet Standardsubstitutionen, die Sie für Builds verwenden können, die von Triggern aufgerufen werden, z. B. Variablenzuordnungen zu dem Trigger- oder Repository-Namen. Sie können außerdem Ihre eigenen Substitutionsvariablen definieren. Weitere Informationen finden Sie unter Variablenwerte ersetzen.

Bash-Parametererweiterungen

Sie können die Bash-Parametererweiterungen auf die Werte der Substitutionsvariablen anwenden. Mit Bash-Parametererweiterungen können Sie Strings bearbeiten, die mit vorhandenen Variablen verknüpft sind. Sie können beispielsweise die Bash-Parametererweiterungen verwenden, um Großbuchstaben zu verwenden oder einen Teilstring zu ersetzen. Weitere Informationen finden Sie unter Bash-Parametererweiterungen.

Nutzlastbindungen

Sie können einen Teil der Ereignisnutzlast als Substitutionsvariable mithilfe von Nutzlastbindungen speichern. Mit einer Nutzlast verknüpfte Variablen werden als Bindungen bezeichnet und sind für Builds verfügbar, die durch Push- und Pull-Ereignisse aufgerufen werden. Sie können Bindungen verwenden, um auf zusätzliche Daten zu Ihrem Build zuzugreifen, z. B. den Autor einer Pull-Anfrage. Weitere Informationen finden Sie unter Nutzlastbindungen.

Genehmigungen

Sie können Trigger so konfigurieren, dass ein Build nicht sofort ausgeführt wird, sondern einen Build bis zur Genehmigung als ausstehend markieren. Wenn ein Nutzer mit Berechtigungen einen ausstehenden Build genehmigt, wird der Build gestartet. Wenn die Genehmigung verweigert wird, startet der Build nicht. Informationen zum Konfigurieren von Triggern, die genehmigt werden müssen, finden Sie unter Builds erst nach Genehmigung starten.

Benachrichtigungen zum Build-Status

Sie können Cloud Build-Benachrichtigungen so konfigurieren, dass Build-Ereignis-Updates aus dem Pub/Sub-cloud-builds-Thema überwacht werden. Notifier können auch Nachrichten filtern, die vom Thema empfangen werden, und Nachrichten an Ihre verbundenen Dienste senden. Cloud Build hält bereitstellbare Benachrichtigungs-Images im cloud-build-notifiers-Repository vor. Sie können Benachrichtigungen mit einem Cloud Build-Notifier wie BigQuery, HTTP, Slack oder SMTP konfigurieren oder Ihren eigenen Notifier erstellen.

Nächste Schritte