Cloud Build-Trigger

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu aktivieren. Sie können Trigger konfigurieren, um auf eingehende Ereignisse zu warten, z. B. wenn ein neuer Commit per Push an ein Repository gesendet oder eine Pull-Anfrage initiiert wird, und dann automatisch einen Build auszuführen, wenn neue Ereignisse eingehen. Sie können Trigger auch so konfigurieren, dass Code für Änderungen an Ihrem Quell-Repository oder nur für Änderungen erstellt wird, die bestimmte Kriterien erfüllen.

Diese Seite bietet einen Überblick über die einzelnen Triggertypen und die mit Triggern verbundenen Funktionen.

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, z. B. Repositories in GitHub oder Bitbucket, mit Cloud Build verbinden oder Code in Cloud Source Repositories für Ihre Builds verwenden. Sie können jedes Quell-Repository mit Cloud Build verbinden. Cloud Build bietet jedoch bestimmte Trigger für Repository-Ereignisse, mit denen Sie bestimmte Quellcode-Verwaltungssysteme (SCMs) einbinden können. In diesem Abschnitt werden die verfügbaren Trigger für Repository-Ereignisse erläutert.

GitHub-Trigger

Sie können GitHub-Trigger erstellen, um Builds als Reaktion auf Repository-Ereignisse wie Push- oder Pull-Anfragen automatisch auszuführen. Sie können den Build-Status des Triggers auf GitHub und in der Google Cloud Console ansehen. Sie können auch die Cloud Build GitHub-Anwendung verwenden, um eine Verbindung zu GitHub herzustellen und Code zu erstellen. Weitere Informationen finden Sie unter Repositories aus 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 werden und nicht über eine öffentliche Internetverbindung erreichbar sind. Mit GitHub Enterprise-Triggern können Builds als Reaktion auf Push- oder Pull-Anfragen von einer GitHub Enterprise-Instanz ausgeführt 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 Sie Builds als Reaktion auf Commit-Push- oder Pull-Anfragen ausführen, 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 mehrmals mit mehreren Hostverbindungen mit Cloud Build verbinden. Weitere Informationen zum Erstellen von Triggern, um Builds als Reaktion auf Ereignisse auszuführen, finden Sie unter Repositories mit Bitbucket Server erstellen.

Bitbucket Data Center-Trigger

Sie können Trigger für Repositories erstellen, die in einer Bitbucket Data Center-Instanz gehostet werden, einschließlich Instanzen, die in einer lokalen Umgebung gehostet werden. Mit Bitbucket Data Center-Triggern können Builds als Reaktion auf Ereignisse wie Commit-Push- oder Pull-Anfragen ausgeführt werden. Weitere Informationen finden Sie unter Repositories aus 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-Push- 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 manuelle Trigger auch so konfigurieren, dass sie nach einem Zeitplan ausgeführt werden. Weitere Informationen finden Sie unter Code manuell in Quell-Repositories 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. Beispielsweise können Sie Pub/Sub-Trigger zum Erstellen als Reaktion auf Image-Übertragungen 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 übertragene 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 Quellcode-Verwaltungssysteme (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 im Trigger definieren, um zu steuern, welche Repositories Ihre Triggerklone während der Build-Zeit klonen, anstatt eine Quelle explizit anzugeben. Weitere Informationen finden Sie unter Builds als Reaktion auf Webhook-Ereignisse automatisieren. Weitere Informationen zur Verwendung von Webhook-Triggern zum Erstellen von Repositories aus bestimmten SCMs finden Sie unter Repositories aus Bitbucket Server erstellen, Repositories aus Bitbucket Cloud erstellen und Repositories aus GitLab erstellen.

Triggerfunktionen

Cloud Build-Trigger bieten Funktionen, mit denen Sie genau steuern können, wie ein Build ausgeführt wird. In diesem Abschnitt werden verschiedene Funktionen im Zusammenhang mit Triggern erläutert.

Geplante manuelle Trigger

Sie können manuelle Trigger so planen, dass Builds automatisch nach einem vordefinierten Zeitplan ausgeführt werden. Sie können beispielsweise einen geplanten Trigger so konfigurieren, dass er jeden Samstag um 6:00 Uhr einen Build ausführt. Zum Planen von Builds können Sie einen manuellen Trigger erstellen und diesen mit Cloud Scheduler aufrufen. Weitere Informationen finden Sie unter Builds planen.

Ereignisse filtern

Cloud Build verwendet Common Expression Language (CEL) mit der Variablen build für Felder, die in der Build-Ressource aufgeführt sind, um auf Felder zuzugreifen, die mit Ihrem Build-Ereignis verknüpft sind, z. B. die Trigger-ID, die Image-Liste oder Substitutionswerte. Sie können den String filter verwenden, um Build-Ereignisse in Ihrer Build-Konfigurationsdatei mit einem beliebigen 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, sondern ein Build bis zur Genehmigung als ausstehend markiert wird. Wenn ein Nutzer mit Berechtigungen einen ausstehenden Build genehmigt, wird der Build gestartet. Wenn die Genehmigung abgelehnt wird, wird der Build nicht gestartet. Informationen zum Konfigurieren von Triggern, die genehmigt werden müssen, finden Sie unter Gate baut auf Genehmigung auf.

Benachrichtigungen zum Build-Status

Sie können Cloud Build-Benachrichtigungen so konfigurieren, dass sie Build-Ereignisaktualisierungen aus dem Pub/Sub-Thema cloud-builds überwachen. Notifier können auch Nachrichten filtern, die nach dem Thema empfangen wurden, und Nachrichten an Ihre verbundenen Dienste senden. Cloud Build stellt bereitstellbare Benachrichtigungs-Images im cloud-build-notifiers-Repository bereit und verwaltet sie. Sie können Benachrichtigungen mit einem Cloud Build-Notifier wie BigQuery, HTTP, Slack oder SMTP konfigurieren oder Ihren eigenen Notifier erstellen.

Nächste Schritte