Cloud Build-Trigger

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu aktivieren. Sie können Konfigurieren Sie Trigger, um eingehende Ereignisse zu erfassen, z. B. wenn ein neuer Commit ausgeführt wird. an ein Repository gesendet oder eine Pull-Anfrage initiiert wird. 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 verbinden, wie Repositories in GitHub oder Bitbucket, in Cloud Build Code in Cloud Source Repositories für Ihre Builds. Sie können zwar jedes Quell-Repository mit Cloud Build, Cloud Build stellt ein bestimmtes Repository bereit Ereignis-Trigger, mit denen Sie die Verwaltung bestimmter Quellcodes einbinden können (SCMs). In diesem Abschnitt werden die verfügbaren Repository-Ereignis-Trigger beschrieben.

GitHub-Trigger

Sie können GitHub-Trigger erstellen, um Builds als Reaktion auf Repository-Ereignissen wie Push- oder Pull-Anfragen. Sie können den Build-Status des Triggers in GitHub und 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. Mit GitHub Enterprise-Triggern können Sie Builds als Antwort auf Push- oder Pull-Anfragen von einer GitHub Enterprise-Instanz. 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 gehostet werden -Instanz, einschließlich Instanzen, die in einem privaten Netzwerk gehostet werden. GitLab Enterprise Mit Edition-Triggern können Builds als Reaktion auf Commit-Pushes oder Pull-Anfragen, die mit Ihrem GitLab Enterprise Edition-Repository verknüpft sind. Bis 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 Trigger zum Ausführen von Builds als Reaktion auf Ereignisse, siehe Repositories aus 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. Ich können Sie auch manuelle Trigger nach einem Zeitplan. 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 eine direkte Verbindung zu externen und externen Quellcode-Management-Systemen (SCMs) wie Bitbucket.com, Bitbucket Server oder GitLab mit Cloud Build. 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 können Sie lernen, wie Sie mithilfe von Webhook-Triggern Repositories aus bestimmten SCMs (siehe Repositories aus Bitbucket Server erstellen) Repositories aus Bitbucket Cloud erstellen 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 die mit Triggern verknüpft sind.

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 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 berechtigter Nutzer eine ausstehende 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 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