Cloud Build-Trigger

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu aktivieren. Sie können Trigger so konfigurieren, dass sie auf eingehende Ereignisse warten, z. B. wenn ein neuer Commit per Push in ein Repository übertragen wird oder wenn eine Pull-Anfrage initiiert wird. Der Build wird dann automatisch ausgeführt, wenn neue Ereignisse eingehen. Sie können Trigger auch so konfigurieren, dass Code bei allen Änderungen an Ihrem Quell-Repository oder nur bei Änderungen erstellt wird, die bestimmte Kriterien erfüllen.

Auf dieser Seite erhalten Sie einen Überblick über die verschiedenen Triggertypen und Funktionen.

Repository-Ereignistrigger

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 zwar jedes Quell-Repository mit Cloud Build verbinden, aber Cloud Build bietet spezifische Repository-Ereignistrigger, die Sie verwenden können, um bestimmte Quellcode-Verwaltungssysteme (SCMs) zu integrieren. In diesem Abschnitt werden die verfügbaren Repository-Ereignistrigger erläutert.

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 Cloud Console aufrufen. Sie können auch die GitHub-Anwendung "Cloud Build" verwenden, um in GitHub eine Verbindung 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. Das gilt auch für Instanzen, die in einer lokalen Umgebung gehostet werden und nicht über eine öffentliche Internetverbindung erreichbar sind. GitHub Enterprise-Trigger können verwendet werden, um Builds als Reaktion auf Push- oder Pull-Anfragen von einer GitHub Enterprise-Instanz auszuführen. Weitere Informationen finden Sie unter Repositories aus GitHub Enterprise erstellen.

Manuelle Trigger

Sie können manuelle Trigger erstellen, um Builds manuell auszuführen und die definierten Werte der Substitutionsvariablen beim Aufruf vor dem Ausführen 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 Manuelle Trigger 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 zum Erstellen von Antworten auf Image-Push-Anfragen zu Artifact Registry verwenden. In diesem Fall können Sie den Trigger so konfigurieren, dass Filter nur ausgeführt werden, wenn das gesendete Image mit einem bestimmten Tag wie prod übereinstimmt. Darüber hinaus können Pub/Sub-Trigger so konfiguriert werden, dass sie ein beliebiges Pub/Sub-Thema abonnieren. Weitere Informationen finden Sie unter Pub/Sub-Trigger erstellen.

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 wie Bitbucket.com, Bitbucket Server oder GitLab direkt mit Cloud Build verbinden. Wenn Sie Webhook-Trigger erstellen, können Sie die Build-Konfiguration auch inline im Trigger definieren, um zu steuern, welche Repositories Ihr Trigger während der Build-Zeit klonen, anstatt eine Quelle explizit anzugeben. Weitere Informationen finden Sie unter Webhook-Trigger erstellen. Informationen zum Erstellen von Repositories aus bestimmten SCMs mit Webhook-Triggern 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 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, der jeden Samstag um 6:00 Uhr ausgeführt wird. Wenn Sie Builds planen möchten, können Sie einen manuellen Trigger erstellen und den Trigger mit Cloud Scheduler aufrufen. Weitere Informationen finden Sie unter Geplante Trigger erstellen.

Ereignisse filtern

Cloud Build verwendet die Common Expression Language (CEL) mit der Variablen build für die in der Build-Ressource aufgeführten Felder, auf die zugegriffen werden kann. Felder, die mit Ihrem Build-Ereignis verknüpft sind, z. B. die Trigger-ID, Image-Liste oder Substitutionswerte. Mit dem String filter können Sie Build-Ereignisse in Ihrer Build-Konfigurationsdatei mit einem beliebigen Feld filtern, das in der Ressource Build aufgeführt ist. Weitere Informationen finden Sie unter CEL zum Filtern von Build-Ereignissen verwenden.

Substitutionsvariablen

Sie können in der Build-Konfigurationsdatei Substitutionsvariablen angeben, um bei der Erstellung bestimmte Werte 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. Sie können z. B. Variablen verwenden, die dem Triggernamen oder Repository-Namen zugeordnet sind. Sie können auch eigene Substitutionsvariablen definieren. Weitere Informationen finden Sie unter Variablenwerte ersetzen.

Bash-Parametererweiterungen

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

Nutzlastbindungen

Sie können einen Teil der Ereignisnutzlast des Triggers als Substitutionsvariable speichern. Dazu verwenden Sie Nutzlastbindungen. Variablen, die einer Nutzlast zugeordnet sind, werden als Bindungen bezeichnet und stehen für Builds zur Verfügung, die von Push- und Pull-Ereignissen aufgerufen werden. Sie können Bindungen verwenden, um auf zusätzliche Daten im Zusammenhang mit 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 Builds nicht sofort ausgeführt, sondern stattdessen als genehmigt gekennzeichnet werden, bis sie genehmigt wurden. Wenn ein Nutzer mit Berechtigungen 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 Builds genehmigen.

Build-Status-Benachrichtigungen

Sie können Cloud Build-Benachrichtigungen so konfigurieren, dass Aktualisierungen von Build-Ereignissen aus dem Pub/Sub-Thema cloud-builds überwacht werden. Benachrichtigungen können auch Nachrichten filtern, die vom Thema empfangen wurden, und Nachrichten an den gewünschten Dienst senden. Cloud Build stellt bereitstellbare Notifier-Images im cloud-build-notifiers-Repository bereit und verwaltet diese. Sie können Benachrichtigungen mit einem Cloud Build-Benachrichtigungsdienst konfigurieren, z. B.BigQuery ,HTTP ,Logo: Slack oderSMTP oderEigene Benachrichtigung erstellen aus.

Nächste Schritte