Cloud Build-Trigger

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 hingegen bietet bestimmte Repository-Ereignis-Trigger, mit denen Sie auf einfache Weise 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 auf 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 von GitHub Enterprise erstellen.

Trigger für GitLab Enterprise Edition

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. GitLab Enterprise Edition-Trigger können verwendet werden, um Builds als Reaktion auf Commit- oder Pull-Anfragen auszuführen, die mit Ihrem GitLab Enterprise Edition-Repository verknüpft sind. Weitere Informationen finden Sie unter Repositories aus 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 zum Ausführen von Builds als Reaktion auf Ereignisse finden Sie unter Repositories über den Bitbucket-Server erstellen.

Bitbucket-Rechenzentrumstrigger

Sie können Trigger für Repositories erstellen, die auf einer Bitbucket-Rechenzentrumsinstanz gehostet werden, einschließlich Instanzen, die in einer lokalen Umgebung gehostet werden. Bitbucket-Rechenzentrumstrigger können zum Ausführen von Builds als Reaktion auf Ereignisse wie Commit-Push- oder Pull-Anfragen verwendet werden. Weitere Informationen finden Sie unter Repositories aus dem Bitbucket-Rechenzentrum 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 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. 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, die Ihnen detaillierte Kontrolle über die Ausführung eines Builds bieten. In diesem Abschnitt werden verschiedene Funktionen für Trigger erläutert.

Manuelle Trigger planen

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.

Builds genehmigen

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 eine Genehmigung erfordern, finden Sie unter Gate-Builds nach Genehmigung.

Benachrichtigungen zum Build-Status

Sie können Cloud Build-Notifier so konfigurieren, dass Build-Ereignis-Updates aus dem Pub/Sub-cloud-builds-Thema überwacht werden. Außerdem können sie die vom Thema empfangenen Nachrichten filtern und an den gewünschten Dienst 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 einen eigenen Notifier erstellen.

Nächste Schritte