Cloud Build-Trigger

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu aktivieren. Sie können Trigger so konfigurieren, dass eingehende Ereignisse überwacht werden, z. B. wenn ein neuer Commit per Push an ein Repository übertragen wird oder wenn eine Pull-Anfrage initiiert wird. Beim Eintreten neuer Ereignisse wird dann automatisch ein Build ausgeführt. Sie können auch Trigger konfigurieren, um Code für Änderungen an Ihrem Quell-Repository oder nur für Änderungen zu erstellen, die bestimmte Kriterien erfüllen.

Diese Seite bietet 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 Code in Cloud Source Repositories für Ihre Builds verwenden. Sie können ein beliebiges Quell-Repository mit Cloud Build verbinden. Cloud Build bietet jedoch spezifische Repository-Ereignistrigger, 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 GitHub-Anwendung Cloud Build verwenden, um eine Verbindung herzustellen und Code in GitHub 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 ausgeführt werden, die auf Push- oder Pull-Anfragen von einer GitHub Enterprise-Instanz reagieren. 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. GitLab Enterprise Edition-Trigger können verwendet werden, um Builds als Antwort auf Commit-Push- 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 mit mehreren Hostverbindungen mehrmals mit Cloud Build verbinden. Weitere Informationen zum Erstellen von Triggern, um Builds als Reaktion auf Ereignisse auszuführen, finden Sie unter Repositories aus Bitbucket Server erstellen.

Bitbucket Data Center-Trigger

Sie können Trigger für Repositories erstellen, die auf einer Bitbucket Data Center-Instanz gehostet werden, einschließlich Instanzen, die in einer lokalen Umgebung gehostet werden. Bitbucket Data Center-Trigger können verwendet werden, um Builds als Reaktion auf Ereignisse wie Commit-Push- oder Pull-Anfragen auszuführen. Weitere Informationen finden Sie unter Repositories aus Bitbucket Data Center erstellen.

Bitbucket Cloud-Trigger

Sie können Trigger für in Bitbucket Cloud gehostete Repositories erstellen. Bitbucket-Cloud-Trigger können verwendet werden, um Builds als Reaktion auf Ereignisse wie Commit-Push- oder Pull-Anfragen auszuführen. 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 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. Sie können Pub/Sub-Trigger beispielsweise für die Erstellung als Reaktion auf Image-Übertragungen in Artifact Registry verwenden. In diesem Fall können Sie den Trigger so konfigurieren, dass ein Build nur dann mit Filtern ausgeführt wird, wenn das übertragene Image mit einem bestimmten Tag wie prod übereinstimmt. Außerdem 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 Antwort auf Webhooks auszuführen. Mit Webhook-Ereignissen, die an eine benutzerdefinierte URL gesendet werden, können Sie externe Systeme und externe Quellcodeverwaltungssysteme 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 Trigger während der Build-Erstellung klonen, anstatt explizit eine Quelle 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 von Triggern 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, der jeden Samstag um 06:00 Uhr einen Build ausführt. Wenn Sie Builds planen möchten, 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 für Felder in der Ressource Build die Common Expression Language (CEL) mit der Variablen build, um auf Felder zuzugreifen, die mit Ihrem Build-Ereignis verknüpft sind, z. B. Trigger-ID, Image-Liste oder Substitutionswerte. Mit dem String filter können Sie Build-Ereignisse in Ihrer Build-Konfigurationsdatei mithilfe eines beliebigen in der Ressource Build aufgeführten Felds filtern. 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 bis zur Genehmigung als ausstehend markiert wird. Wenn ein berechtigter Nutzer einen ausstehenden Build genehmigt, wird der Build gestartet. Wenn die Genehmigung verweigert wird, wird der Build nicht gestartet. Informationen zum Konfigurieren von Triggern, die genehmigt werden müssen, finden Sie unter Gate-Builds bei Genehmigung.

Benachrichtigungen zum Build-Status

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

Nächste Schritte