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 auch Trigger zum Erstellen von Code für Änderungen an Ihrem Quell-Repository oder nur die bestimmte Kriterien erfüllen.

Diese Seite bietet einen Überblick über jeden Triggertyp und die zugehörigen Funktionen mit Triggern.

Trigger für Repository-Ereignisse

Mit Cloud Build können Sie Builds automatisch für Repositorys ausführen wie Push- oder Pull-Anfragen. 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 Trigger für Repository-Ereignisse erläutert.

GitHub-Trigger

Sie können GitHub-Trigger erstellen, um Builds als Reaktion auf Repository-Ereignissen wie Push- oder Pull-Anfragen. Sie können den Trigger auf GitHub und in der Google Cloud Console. Sie können auch die Cloud Build-GitHub-Anwendung um 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 über eine öffentliche Internetverbindung. 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 für Cloud Build mit mehreren Hostverbindungen vervielfältigen können. 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 in einem Bitbucket Data Center gehostet werden -Instanz, einschließlich Instanzen, die in einer lokalen Umgebung gehostet werden. Bitbucket Rechenzentrums-Trigger können verwendet werden, um Builds als Reaktion auf Ereignisse wie Commit-, Push- oder Pull-Anfragen. 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 folgende Ereignisse auszuführen: Commit-, Push- oder Pull-Anfragen. 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 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. So können Sie beispielsweise Pub/Sub-Trigger zum Erstellen als Reaktion auf Image-Übertragungen an Artifact Registry. In diesem Fall können Sie den Trigger so konfigurieren, Einen Build nur ausführen, wenn das übermittelte Image mit einem bestimmten Tag übereinstimmt, z. B. prod Außerdem können Pub/Sub-Trigger so konfiguriert werden, einem beliebigen Pub/Sub-Thema. 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 eine direkte Verbindung zu externen und externen Quellcode-Management-Systemen (SCMs) wie Bitbucket.com, Bitbucket Server oder GitLab mit Cloud Build. Wann? Wenn Sie Webhook-Trigger erstellen, können Sie Ihre Build-Konfiguration auch inline definieren. bei Ihrem Trigger, um zu steuern, welche Repositories Ihre Trigger-Klone während des Build-Prozesses statt explizit eine Quelle anzugeben. Weitere Informationen finden Sie unter Builds als Reaktion auf Webhook-Ereignisse automatisieren Außerdem erfahren Sie, wie Sie mithilfe von Webhook-Triggern Repositories aus bestimmte SCMs (siehe Repositories aus Bitbucket Server erstellen) Repositories aus Bitbucket Cloud erstellen und Repositories aus GitLab erstellen.

Triggerfunktionen

Cloud Build-Trigger bieten Funktionen, die Ihnen detaillierte wie ein Build ausgeführt wird. In diesem Abschnitt werden verschiedene die mit Triggern verknüpft sind.

Geplante manuelle Trigger

Sie können manuelle Trigger planen, um Builds automatisch auf einer vordefinierten Zeitplan. Sie können z. B. einen geplanten Trigger konfigurieren, jeden Samstag um 06:00 Uhr einen Build auszuführen. Um Builds zu planen, haben Sie folgende Möglichkeiten: manuellen Trigger erstellen und rufen Sie den Trigger mit Cloud Scheduler auf. Weitere Informationen finden Sie unter Builds planen

Ereignisse filtern

Cloud Build nutzt Common Expression Language (CEL) mit dem Variable build für die Felder in der Build-Ressource für den Zugriff die mit dem Build-Ereignis verknüpft sind, z. B. die Trigger-ID, die Image-Liste oder Substitutionswerte. Mit dem String filter können Sie Build-Ereignisse filtern, Ihre Build-Konfigurationsdatei mit einem beliebigen im Build-Ressource erstellen. 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, sondern nur markiert wird. ein Build bis zur Genehmigung den Status „Ausstehend“ hat. Wenn ein berechtigter Nutzer eine ausstehende wird der Build gestartet. Wenn die Genehmigung verweigert wird, wird der Build nicht gestartet. Bis wie Sie Trigger konfigurieren, finden Sie unter Gate baut auf Genehmigung auf.

Benachrichtigungen zum Build-Status

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

Nächste Schritte