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
- Weitere Informationen finden Sie unter Build-Trigger erstellen und verwalten.