Mit Tekton-Pipelines arbeiten
Tekton Pipelines ist ein Open-Source-Projekt, mit dem Sie Continuous Integration und Continuous Delivery Pipelines innerhalb eines Kubernetes Clusters konfigurieren und ausführen können. Tekton-Pipelines werden in YAML-Dateien definiert, die typischerweise in einem Git-Repository gespeichert sind.
Tekton bietet eine Reihe von benutzerdefinierten Ressourcenerweiterungen für Kubernetes, um Pipelines zu definieren. Die folgenden grundlegenden Tekton Pipeline-Ressourcen sind in diesen Erweiterungen enthalten:
Ressource | Beschreibung |
---|---|
Task |
Definiert einen Satz von Buildschritten, z. B. das Kompilieren von Code, das Ausführen von Tests und das Erstellen und Bereitstellen von Images. |
TaskRun |
Instanziiert eine Task zur Ausführung mit bestimmten Eingaben, Ausgaben und Ausführungsparametern. Sie können die Task eigenständig oder als Teil einer Pipeline starten. |
Pipeline |
Definiert den Satz von Tasks, die eine Pipeline bilden. |
PipelineRun |
Instanziiert eine Pipeline zur Ausführung mit bestimmten Eingaben, Ausgaben und Ausführungsparametern. |
Sie können die folgenden Funktionen nutzen, wenn Sie Tekton Pipelines verwenden:
- Cloud-nativ: Tekton-Pipelines werden unter Kubernetes ausgeführt, verwenden Kubernetes-Cluster als ersten Klassentyp und Container als Bausteine.
- Entkoppelt: Sie können eine Pipeline für die Bereitstellung in jedem beliebigen Kubernetes-Cluster verwenden. Sie können die Tasks, aus denen sich eine Pipeline zusammensetzt, isoliert ausführen. Und Sie können Ressourcen (wie Git-Repositorys) zwischen Pipelineausführungen wechseln.
- Typisiert: Sie können Implementierungen für bestimmte Typen von Ressourcen, z. B. Bilder, wechseln.
Das Tekton Pipelines-Projekt ist ein Beta-Release. Sie müssen Ihre Pipeline mit jeder neuen Version von Tekton aktualisieren. Weitere Informationen über die neueste Version von Tekton finden Sie unter https://github.com/tektoncd/pipeline/releases.
IBM Cloud® Continuous Delivery stellt zwei Typen von Delivery Pipelines bereit, die Sie zum Erstellen, Testen und Bereitstellen Ihrer Anwendungen verwenden können.
- Klassisch: Klassische Delivery Pipelines werden grafisch erstellt, wobei der Status im Pipelinediagramm eingebettet ist. Diese Pipelines können auf gemeinsam genutzten Workern in der Cloud oder auf privaten Workern in Ihrem eigenen Kubernetes-Cluster ausgeführt werden.
- Tekton: Tekton-Delivery Pipelines werden in YAML-Dateien erstellt, die Pipelines als einen Satz von Kubernetes-Ressourcen definieren. Sie können diese yaml-Dateien bearbeiten, um das Verhalten einer Pipeline zu ändern. Tekton-Pipelines können auf privaten Workern ausgeführt werden, die in Ihrem eigenen Cluster ausgeführt werden. Sie können auch auf von IBM verwalteten Workern in der öffentlichen Cloud ausgeführt werden. Die Tekton-Integration bietet ein Dashboard, mit dem Sie den Status von Tekton-Pipelineläufen anzeigen und neue Läufe auslösen können. Außerdem werden Mechanismen zur Angabe der Pipelineauslöser, der Pipelinedefinitionen, des Workers, auf dem die Pipeline ausgeführt wird, und der Pipelineeigenschaften bereitgestellt.
Beide Typen von Pipelines isolieren Jobs oder Schritte voneinander, indem sie in separaten Containern ausgeführt werden und ein von Ihnen ausgewähltes Image verwenden. Klassische und Tekton-Pipelines sind beide in einer Toolchain enthalten und hängen von dieser Toolchain ab, um weitere Toolintegrationen hinzuzufügen, die im Build-, Test- und Bereitstellungsprozess verwendet werden.
Am 20. November 2020 wurde bei Docker Hub eine Durchsatzbegrenzung für anonyme Image-Pull-Operationen eingeführt. Diese Änderung kann Auswirkungen für Benutzer haben, die Tasks ausführen, bei denen in Docker Hub gehostete Images referenziert werden. Es wird empfohlen, eine alternative Registry zu verwenden, z. B. IBM Cloud Container Registry.
Voraussetzungen
Bevor Sie eine Tekton-Pipeline hinzufügen und ausführen, stellen Sie sicher, dass die folgenden Ressourcen vorhanden sind:
-
Eine Toolchain, die die folgenden Toolintegrationen enthält:
- Eine Repository-Toolintegration (z. B. die GitHub-Toolintegration), die Ihren Tekton-Pipelinecode enthält, einschließlich Tekton-YAML-Datei. Beispiele für Pipeline- und Aufgabendefinitionen finden Sie unter GitHub. Weitere Informationen zu den ersten Schritten mit Tekton Pipelines finden Sie unter Tekton Pipelines.
- Optional. Wenn Sie nicht den standardmäßigen, gemeinsam genutzten Pipeline-Worker verwenden, können Sie eine private Delivery Pipeline-Worker-Toolintegration verwenden, die Ihren Kubernetes-Cluster referenziert. Weitere Informationen zu privaten Workern finden Sie unter Private Delivery Pipeline-Worker installieren.
-
Lokal installierte IBM Cloud-Befehlszeilenschnittstelle.
-
kubectl wird lokal installiert.
-
Ein Kubernetes-Cluster (Version 1.22 oder höher), wie z. B. ein IBM Cloud® Kubernetes Service-Cluster
Die Toolchain und die Delivery Pipeline Private Worker-Toolintegration müssen sich in derselben Region befinden.
Delivery Pipeline für Tekton mithilfe der Konsole erstellen
Wenn Sie eine Delivery Pipeline-Toolintegration konfigurieren, können Sie den Typ von Pipeline auswählen, den Sie erstellen möchten.
-
Wenn Sie keine Werkzeugkette haben, wählen Sie eine Vorlage, um eine Werkzeugkette zu erstellen. Abhängig von der Vorlage, die Sie verwenden, sind unterschiedliche Felder verfügbar. Überprüfen Sie die Standardfeldwerte und ändern Sie diese Einstellungen gegebenenfalls.
-
Wenn Sie eine Toolchain haben und diese Toolintegration hinzufügen, klicken Sie in der Konsole IBM Cloud auf das
Menü > Plattformautomatisierung > Toolchains. Klicken Sie auf der Seite Toolchains auf die Toolchain, um deren Übersichtsseite zu öffnen. Alternativ können Sie auf der Übersichtsseite Ihrer App auf der Karte für Continuous Delivery auf Toolchain anzeigen klicken. Klicken Sie anschließend auf Übersicht.
-
Fügen Sie die Delivery Pipeline-Integration zur Toolchain hinzu:
a. Klicken Sie auf Tool hinzufügen.
b. Klicken Sie im Abschnitt mit den Toolintegrationen auf Delivery Pipeline.
-
Geben Sie einen Namen für Ihre neue Pipeline an.
-
Wählen Sie Tekton aus, um eine Tekton-Delivery Pipeline zu erstellen. Sie können die Ausgabe von Tekton-Pipeline-Läufen auf einem definierten Kubernetes-Cluster anzeigen, mit Unterstützung für die Konfiguration der Pipeline-Definitions-Repos, der Pipeline-Auslöser, des Ortes, an dem die Pipeline läuft, und einfacher Geheimnisse.
-
Wenn Sie mithilfe Ihrer Pipeline eine Benutzerschnittstelle bereitstellen möchten, wählen Sie das Kontrollkästchen Apps im Menü 'App anzeigen' anzeigen aus. Alle Apps, die Ihre Pipeline erstellt, werden in der Liste App anzeigen auf der Übersichtsseite der Toolchain angezeigt.
-
Klicken Sie auf Integration erstellen, um die Delivery Pipeline zu Ihrer Toolchain hinzuzufügen.
Delivery Pipeline für Tekton über die Konsole konfigurieren
-
Klicken Sie auf der Übersichtsseite Ihrer Toolchain auf der Karte Lieferpipelines auf die Schaltfläche Delivery Pipeline um die Seite Tekton Delivery Pipeline Overview zu öffnen.
-
Klicken Sie auf Einstellungen. Führen Sie im Abschnitt Definitionen die folgenden Tasks aus:
a. Geben Sie das Git-Repository und die URL an, die die Tekton-Pipelinedefinition und zugehörige Artefakte enthält. Wenn das Repository nicht verfügbar ist, rufen Sie die Übersichtsseite der Toolchain erneut auf und fügen Sie das Repository hinzu.
b. Wählen Sie den Zweig in Ihrem Git-Repository aus, den Sie verwenden möchten, oder geben Sie einen Tag ein.
c. Geben Sie den Pfad zu Ihrer Pipelinedefinition im Git-Repository an. Sie können eine bestimmte Definition im selben Repository referenzieren. Es ist ebenfalls möglich, mehrere Definitionsrepositorys hinzuzufügen, wenn diese in die Toolchain integriert sind.
d. Speichern Sie Ihre Änderungen.
Die Pipelinedefinition wird automatisch aktualisiert.
Die berechnete Größenbegrenzung für die Pipelinedefinition beträgt 1 MB. Wenn beim Speichern oder Ausführen Ihrer Pipeline Fehler auftreten, müssen Sie möglicherweise die Größe Ihrer Pipelinedefinition reduzieren oder sie in mehrere Pipelines aufteilen.
-
Wählen Sie im Abschnitt Worker den von IBM verwalteten, gemeinsam genutzten Worker oder den privaten Worker aus, der für die Ausführung der Tekton-Pipeline verwendet werden soll. Weitere Informationen zu privaten Workern finden Sie unter Mit privaten Delivery Pipeline-Workern arbeiten.
Der private Worker muss in derselben Toolchain wie Ihre Tekton-Pipeline definiert werden.
-
Klicken Sie im Abschnitt Umgebungseigenschaften auf Hinzufügen und wählen Sie einen Eigenschaftstyp aus, um Ihre eigene Umgebungseigenschaft zu definieren. Sie können beispielsweise eine Eigenschaft
API_KEY
definieren, die einen API-Schlüssel übergibt, der von allen Scripts in der Pipeline für den Zugriff auf IBM Cloud-Ressourcen verwendet wird. Sie können die folgenden Typen von Eigenschaften hinzufügen:- Enumeration: Ein Eigenschaftsschlüssel mit einem Wert, der aus einer benutzerdefinierten Liste von Optionen ausgewählt werden kann.
- Secure value: Ein Eigenschaftsschlüssel mit einem einzeiligen Wert, der mit der AES-128-Verschlüsselung gesichert ist. Dieser Wert wird mithilfe des Sternzeichens angezeigt. Alternativ können Sie auf das Schlüsselsymbol klicken, um einen geheimen Schlüssel aus einer Vault-Integration auszuwählen (z. B. IBM Key Protect), wenn ein solches Tool in Ihrer Toolchain verfügbar ist.
- Text value: Ein Eigenschaftsschlüssel mit einem Textwert, der einzeilig oder mehrzeilig sein kann. Bisher wurden mehrzeilige Werte durch einen separaten Eigenschaftstyp Text area unterstützt.
- Tool integration: Ein Eigenschaftsschlüssel mit einem Wert, der während der Ausführung von einer Toolchain-Tool-Integration aufgelöst wird. Standardmäßig handelt es sich bei dem Wert um eine JSON-Zeichenfolgedarstellung
der Toolintegration. Ein bestimmtes Feld oder ein bestimmter Teil des Objekts kann abgerufen werden, indem ein Wert für den optionalen JSON-Filter angegeben wird. Wenn beispielsweise eine GitHub-Integration ausgewählt und der JSON-Filter
parameters.repo_url
angegeben wird, gibt der Wert die URL des Git-Repositorys wieder, das in der Toolintegration konfiguriert ist, wenn die RessourcePipelineRun
ausgeführt wird.
Sie können auf diese Eigenschaften in Ihren Tekton-Pipelineressourcen zugreifen. Weitere Informationen zu diesen Eigenschaften finden Sie in Umgebung und Ressourcen von Tekton-Pipelines.
Eigenschaften können gesperrt werden, um zu verhindern, dass sie überschrieben werden. Der Versuch, eine gesperrte Eigenschaft zur Laufzeit zu überschreiben, führt dazu, dass die Ausführungsanforderung zurückgewiesen wird. Gesperrte Eigenschaften werden standardmäßig nicht im Seitenfenster für die Ausführung angezeigt, können aber schreibgeschützt angezeigt werden, indem die Option 'Alle Eigenschaften anzeigen' aktiviert wird.
-
Klicken Sie auf Speichern.
-
Klicken Sie auf der Seite Pipeline-Übersicht auf Hinzufügen, um einen Auslöser zu erstellen, wählen Sie den Typ des hinzuzufügenden Auslösers aus, und verknüpfen Sie den Auslöser mit einem Ereignis-Listener. Die Liste der verfügbaren Ereignislistener enthält die Listener, die im Pipeline-Code-Repository definiert sind.
Die Trigger basieren auf den Tekton-Triggerdefinitionen. Git repo-Trigger verwenden den Ereignis-Listener, dem sie zugeordnet sind, um Informationen aus der eingehenden Ereignis-Nutzlast zu extrahieren und Kubernetes Ressourcen zu erstellen. Diese Ressourcen werden auf die Tekton-Ressource
PipelineRun
angewendet.Ausgelöste Pipelineausführungen werden gleichzeitig ausgeführt, es sei denn, Sie konfigurieren den Auslöser für die Serialisierung von Ausführungen mithilfe der Option
Limit concurrent runs
. Wenn diese Option aktiviert ist, können Sie die Anzahl der gleichzeitigen Ausführungen begrenzen, die durch diesen Auslöser gestartet werden können. Wenn der Maximalwert beispielsweise auf 1 gesetzt ist, wird jeweils nur eine Pipelineausführung für diesen Auslöser ausgeführt und alle anderen werden im Wartestatus in die Warteschlange gestellt. Maximal 20 Läufe (5, wenn Sie IBM Managed Workers verwenden) werden in eine Warteschlange eingereiht, bevor nachfolgende Anfragen automatisch abgebrochen werden. Standardmäßig sind alle zeitgesteuerten Auslöser auf eine gleichzeitige Ausführung beschränkt, wenn IBM Managed Workers verwendet wirdManuelle Auslöser werden ausgeführt, wenn Sie auf die Schaltfläche Ausführen für die Pipeline klicken und den Auslöser auswählen.
Git-Repository-Auslöser werden ausgeführt, wenn der angegebene Git-Ereignistyp für das angegebene Git-Repository und den angegebenen Zweig auftritt.
Sie können auf die Webhooknutzdaten zugreifen, die von Ihren Tekton-Pipelineressourcen an einen Git-Auslöser übergeben wurden. Obwohl die genauen Felder Repo-spezifisch sind, lautet die allgemeine Syntax für die Webhooknutzdaten
$(event.payloadFieldName)
. Bevor Sie einen Webhook erstellen können, müssen Sie die Git-Administratorzugriffsberechtigung für die entsprechende Git-Integration autorisieren. Zum Autorisieren der Git-Administratorzugriffsberechtigung ist das erneute Konfigurieren und Speichern der Git-Integration erforderlich.Zeitgesteuerte Auslöser werden zu einer geplanten Zeit ausgeführt, die durch den CRON-Wert definiert ist. Der CRON-Ausdruck für zeitgesteuerte Auslöser basiert auf der UNIX crontab-Syntax und ist eine Folge von fünf Zeit- und Datumsfeldern:
minute
,hour
,day of the month
,month
, undday of the week
. Diese Felder werden durch Leerzeichen im FormatX X X X X
getrennt. Die maximale Häufigkeit für einen zeitgesteuerten Auslöser beträgt einmal alle fünf Minuten. Die folgenden Beispiele zeigen Zeichenfolgen, die verschiedene zeitgesteuerte Frequenzen verwenden.*/5 * * * *
- Der Auslöser wird alle 5 Minuten ausgeführt.0 * * * *
- Der Auslöser wird zu Beginn jeder Stunde ausgeführt.0 9 * 1 MON-FRI
- Der Auslöser wird im Januar von Montag bis Freitag um 9:00 Uhr ausgeführt.0 * * NOV,DEC 1
- Der Auslöser wird jeweils montags im November und Dezember stündlich ausgeführt.
Auslöser für generische Webhooks werden ausgeführt, wenn eine POST-Anforderung, für die die Einstellung 'secret' konfiguriert ist, an die URL des generischen Webhooks gesendet wird. Auslöser für generische Webhooks geben eine eindeutige Webhook-URL für POST-Anforderungen an.
Da die PipelineRun-Benutzerschnittstelle die Nutzdatenwerte des generischen Webhooks im Abschnitt mit den Ereignisnutzdaten nicht ausblendet, dürfen in den Nutzdaten keine sensiblen Daten enthalten sein. Schützen Sie stattdessen alle für einen generischen Webhook erforderlichen Daten durch Auslösereigenschaften. Hierzu gehören zum Beispiel Kennwörter oder geheime API-Schlüssel.
Sie können Auslöser für generische Webhooks zur Verwendung mit Git, einem ausgehenden Slack-Webhook, einem Artifactory-Webhook und weiteren Webhooks schützen, indem Sie eine der folgenden Methoden verwenden:
- Tokenabgleich zum Vergleichen des gespeicherten Tokens mit dem Token, das in der POST-Anforderung übergeben wird. Zu den unterstützten Tokenquellen gehören Header, Abfragen oder Nutzdaten. Ein Tokenabgleich wird von GitLab-Webhooks und ausgehenden Slack-Webhooks verwendet.
- Abgleich von Nutzdatendigests zum Vergleichen der Signatur und des Hashwerts, die auf der Basis des Nutzdatendigests generiert werden, indem HMAC.hexdigest mit einem gespeicherten Token verwendet wird. Zu den unterstützten Signaturquellen können Header, Abfragen oder Nutzdaten gehören. Benutzer müssen einen Hashalgorithmus angeben. Ein Abgleich von Nutzdatendigests wird von GitHub-Webhooks verwendet.
- Bei der Tekton-Taskvalidierung müssen Benutzer die Webhookanforderung innerhalb ihrer Tekton-Tasks validieren.
Geben Sie die folgenden Werte an, um Auslöser für generische Webhooks mit GitHub-Webhooks zu verwenden:
- Schutz:
Payload Digest Matches
- Signaturquelle:
Header
- Headerschlüsselname:
X-Hub-Signature
- Hashalgorithmus:
sha1
.
Geben Sie die folgenden Werte an, um Auslöser für generische Webhooks mit GitLab-Webhooks zu verwenden:
- Schutz:
Token Matches
- Tokenquelle:
Header
- Headerschlüsselname:
X-Gitlab-Token
Geben Sie die folgenden Werte an, um Auslöser für generische Webhooks mit ausgehenden Slack-Webhooks zu verwenden:
- Schutz:
Token Matches
- Tokenquelle:
Payload
- JSON-Eigenschaftsname / Formatschlüssel:
token
Das folgende Beispiel zeigt, wie der curl-Befehl mit einem generischen Webhook verwendet wird, der durch eine Regel für den
Token Matches
geschützt wird:caption-side=bottom" curl -X POST \ https://devops-api.us-south.devops.cloud.ibm.com/v1/tekton-webhook/588236be-749b-4c67-ae57-a561abbbc9a8/run/7e82880e-4223-4c98-8ca9-ef6df36bb6dc \ -H 'Content-Type: application/json' \ -H 'token: 48a0f92c0932890048596906a22ae189c48c5619fbcf9600' \ -d '{ "somekey": "somevalue" }'
Geben Sie zum Abrufen von Nutzdatenwerten in der Pipelinedefinition einen Triggerbindungsparameter mit einem Wert an, der vom Ereignis abgeleitet ist:
apiVersion: tekton.dev/v1beta1 kind: TriggerBinding metadata: name: binding spec: params: - name: somekey value: $(event.somekey)
Speichern Sie Ihre Änderungen.
Darüber hinaus unterstützen generische Webhook-Trigger die Übergabe von Eigenschaften im Body der Webhook-Anfrage. Dadurch können die Eigenschaften für die PipelineRun, die durch den Webhook ausgelöst wird, überschrieben werden, oder es können zusätzliche Eigenschaften übergeben werden, die die in der PipelineRun verwendeten Pipeline-/Auslösereigenschaften ergänzen.
Wenn Sie in den Nutzdateneigenschaften sensible Daten wie Kennwörter oder API-Schlüsselgeheimnisse angeben müssen, sollten Sie den Eigenschaftstyp
SECURE
für solche Eigenschaften verwenden, damit sie in der Benutzeroberfläche nicht im Klartext angezeigt werden.Darüber hinaus kann eine optionale Beschreibung im Anforderungskörper übergeben werden, die die PipelineRun beschreibt, die ausgelöst wird, und die in der Benutzeroberfläche angezeigt wird, wenn die PipelineRun Details in einem Browser angezeigt werden.
Das folgende Beispiel zeigt, wie man den Befehl curl mit einem generischen Webhook verwendet und dabei eine Texteigenschaft, eine sichere Eigenschaft und eine Beschreibung übergibt:
curl -X POST \ https://devops-api.us-south.devops.cloud.ibm.com/v1/tekton-webhook/588236be-749b-4c67-ae57-a561abbbc9a8/run/7e82880e-4223-4c98-8ca9-ef6df36bb6dc \ -H 'Content-Type: application/json' \ -H 'token: 48a0f92c0932890048596906a22ae189c48c5619fbcf9600' \ -d '{ "description":"This text can be used to describe the PipelineRun that will be triggered by this request.", "properties":[ {"name":"mytextprop","type":"TEXT","value":"my text value"}, {"name":"mysecureprop","type":"SECURE","value":"mysecret"} ] }'
Konfigurieren von Delivery Pipeline Triggern für Tekton-Pipelines
Sie können Auslöser für Tekton-Pipelines konfigurieren, die auf verschiedenen Ereignissen in Ihrem Git Repo basieren. Filtern Sie Git-Auslöser mit Hilfe der folgenden Optionen:
- Zweig: Löst die Pipeline für einen bestimmten Zweig des ausgewählten Repos aus, wenn das angegebene Ereignis eintritt.
- Muster: Lösen Sie die Pipeline auf der Grundlage einer Glob-Übereinstimmung mit Tags und Zweignamen im ausgewählten Projektarchiv aus, wenn das angegebene Ereignis eintritt.
- CEL-Filter: Lösen Sie die Pipeline aus, wenn das Ereignis mit dem angegebenen CEL-Filter (Common Expression Language) übereinstimmt.
Verwenden Sie die Optionen "Verzweigung" und " Muster", um Ereignisse wie " commit push
, " pull request opened
, " updated
oder "
closed
anzugeben. Sie können auch Pull-Request-Ereignisse angeben, indem Sie die Option Include draft pull request events (Pull-Request-Ereignisse für Entwürfe einschließen ) aktivieren, um Pipeline-Trigger
für Pull-Requests zuzulassen oder zu überspringen. In ähnlicher Weise können Sie angeben, ob Sie Pipeline-Trigger für Pull-Requests aus geforkten Repositories zulassen möchten, indem Sie die Option Pull-Request-Ereignisse aus Forks einschließen aktivieren. Zusätzlich können Sie die Option Label-Filter auswählen, um die Filterung auf der Grundlage von Pull Request Labels nach benutzerdefinierten Kriterien in der Filtertabelle zu aktivieren.
Die CEL-Filteroption unterstützt erweiterte Anwendungsfälle, z. B. den Abgleich mit anderen Feldern in der Ereignisnutzlast. Diese Option unterstützt Push-Ereignisse, alle Pull-Request-Ereignisse, Issue-Ereignisse, Issue-Kommentar-Ereignisse und Release-Ereignisse. Diese Option ist auch als optionale Funktion für den generischen Webhook-Trigger verfügbar, um die Ereignisfilterung auf der Grundlage der Webhook-Nutzdaten zu ermöglichen.
CEL-Übersicht
CEL ist eine leistungsstarke und flexible Ausdruckssprache, die für die Bewertung von Bedingungen und die Durchführung von Validierungen in einer prägnanten und lesbaren Weise entwickelt wurde. CEL eignet sich ideal für Anwendungsfälle, die eine komplexe bedingte Logik erfordern, wie z. B. das Filtern von Ereignissen.
In der Tekton-Pipeline wurde die Option CEL eingeführt, um eine leistungsfähigere und flexiblere Ereignisfilterung zu ermöglichen. Die Webhook-Nutzdaten werden anhand des CEL-Ausdrucks ausgewertet, der vom Benutzer angegeben wird. Wenn der
CEL-Ausdruck den Wert true
ergibt, wird der Pipelinelauf ausgelöst.
Die folgenden Funktionen werden in CEL unterstützt:
- Arithmetische Operatoren (
+
,-
,*
,/
,%
) - Vergleichsoperatoren (
=
,!=
,<
,>
,<=
,>=
) - Logische Operatoren (
&&
,||
) - String-Operatoren (
contains
,matches
,startsWith
,endsWith
) - Sammlungsoperatoren (
in
,!in
) - Variablen (verweisen auf Variablen direkt durch ihre Namen)
- Literale (unterstützt Literale wie Strings, Zahlen, Boolesche Werte und Null)
CEL enthält die folgenden Erweiterungen, um der Basissprache CEL mehr Funktionalität zu verleihen:
Sets extension
, um erweiterte Mengenoperationen zu unterstützen und mehr Flexibilität bei der Ereignisfilterung zu bieten. Weitere Informationen zu dieser Erweiterung finden Sie unter Sets.matchesGlob
, um die Kompatibilität bei der Umwandlung des bestehenden Musterfeldes in die neue CEL-Filteroption zu gewährleisten. Der native CEL-Operatormatches
wird für den erweiterten Abgleich regulärer Ausdrücke empfohlen.
Weitere Informationen über CEL finden Sie in der CEL-Dokumentation.
Umstellung auf CEL
Führen Sie die folgenden Schritte aus, um Ihre vorhandene Ereignisfilterauswahl in einen CEL-Ausdruck umzuwandeln:
-
Bearbeiten Sie den Git-Auslöser, den Sie konvertieren möchten.
-
Wählen Sie im Abschnitt Auslösen bei die Option CEL-Filter.
caption-side=bottom" Die folgenden Elemente werden automatisch in einen entsprechenden CEL-Ausdruck umgewandelt:
- Zweig oder Muster
- Ereignisse, wie
commit push
,pull request opened
,updated
undclosed
- Pull-Request-Ereignisse in den Entwurf aufnehmen
- Pull-Request-Ereignisse von Forks einbeziehen
- Beschriftungsfilter
CEL-Filterumbau Der generierte CEL-Ausdruck wird in ein Textfeld geschrieben, das Sie nach Bedarf bearbeiten können.
Da für generische Webhook-Trigger keine Filter für die Konvertierung existieren, gilt die Konvertierung in einen CEL-Filter nur für Git-Trigger.
Wenn Sie den Auslöser mit ausgewählter CEL-Option speichern, werden die zuvor ausgewählten Ereignisse durch den CEL-Ausdruck ersetzt. Wenn Sie zur Option Zweig oder Muster wechseln, nachdem Sie die CEL-Filteroption gespeichert haben, werden Ihre vorherigen Ereignisauswahlen nicht gespeichert. Eine Konvertierung von der Option CEL in die Option Zweig oder Muster wird nicht unterstützt.
Beispiele für CEL-Ausdrücke
Die folgenden Beispiele sind allgemeine CEL-Ausdrücke für jeden der unterstützten Git-Typen: GitHub
, GitLab
und BitBucket
. Sie können diese Beispiele kopieren und an Ihre Bedürfnisse anpassen.
GitHub Beispiele:
Wird ausgeführt, wenn eine Pull-Anfrage für den angegebenen Zweig geöffnet oder aktualisiert wird:
header['x-github-event'] == 'pull_request' &&
(body.action == 'opened' || body.action == 'synchronize') &&
body.pull_request.base.ref == 'main'
Wird ausgeführt, wenn ein Commit in den angegebenen Branch verschoben wird:
header['x-github-event'] == 'push' && body.ref == 'refs/heads/main'
Wird ausgeführt, wenn eine Übergabe an den angegebenen Zweig erfolgt, aber übersprungen, wenn die Übergabemeldung eine bestimmte Zeichenfolge enthält:
header['x-github-event'] == 'push' &&
body.ref == 'refs/heads/main' &&
!body.head_commit.message.contains("skip run")
Wird ausgeführt, wenn ein Kommentar, der die angegebene Zeichenfolge enthält, zu einer Pull-Anfrage hinzugefügt wird:
header['x-github-event'] == 'issue_comment' &&
body.action == 'created' && has(body.issue.pull_request) &&
body.comment.body.contains('/lgtm')
Wird ausgeführt, wenn eine Ausgabe mit dem angegebenen Label erstellt wird:
header['x-github-event'] == 'issues' &&
body.action == 'opened' &&
body.issue.labels.exists(label, label.name == 'urgent')
GitLab Beispiele:
Wird ausgeführt, wenn eine Zusammenführungsanforderung für den angegebenen Zweig geöffnet oder aktualisiert wird:
header['x-gitlab-event'] == 'Merge Request Hook' &&
(body.object_attributes.action == 'open' || body.object_attributes.action == 'update') &&
body.object_attributes.target_branch == 'main'
Wird ausgeführt, wenn ein Commit in den angegebenen Branch verschoben wird:
header['x-gitlab-event'] == 'Push Hook' && body.ref == 'refs/heads/main'
Wird ausgeführt, wenn eine Übergabe an den angegebenen Zweig erfolgt, aber übersprungen, wenn die Übergabemeldung eine bestimmte Zeichenfolge enthält:
header['x-gitlab-event'] == 'Push Hook' &&
body.ref == 'refs/heads/main' &&
!body.object_attributes.last_commit.message("skip run")
Wird ausgeführt, wenn ein Kommentar, der die angegebene Zeichenfolge enthält, zu einer Zusammenführungsanfrage hinzugefügt wird:
header['x-gitlab-event'] == 'Note Hook' &&
body.object_attributes.noteable_type == 'MergeRequest' &&
body.object_attributes.action == 'create' &&
body.object_attributes.note.contains('/lgtm')
Wird ausgeführt, wenn eine Ausgabe mit dem angegebenen Label erstellt wird:
header['x-gitlab-event'] == 'Issue Hook' &&
(body.object_attributes.action == 'open') &&
body.object_attributes.labels.exists(label, label.name == 'urgent')
BitBucket Beispiele:
Wird ausgeführt, wenn eine Pull-Anfrage für den angegebenen Zweig geöffnet oder aktualisiert wird:
(header['x-event-key'] == 'pullrequest:created' || header['x-event-key'] == 'pullrequest:updated') &&
body.pullrequest.destination.branch.name == 'main'
Wird ausgeführt, wenn ein Commit in den angegebenen Branch verschoben wird:
header['x-event-key'] == 'repo:push' && body.push.changes[0].new.name == 'main'
Wird ausgeführt, wenn eine Übergabe an den angegebenen Zweig erfolgt, aber übersprungen, wenn die Übergabemeldung eine bestimmte Zeichenfolge enthält:
header['x-event-key'] == 'repo:push' &&
body.push.changes[0].new.name == 'main' &&
!body.push.changes[0].commits[0].message("skip run")
Wird ausgeführt, wenn ein Kommentar, der die angegebene Zeichenfolge enthält, zu einer Pull-Anfrage hinzugefügt wird:
header['x-event-key'] == 'pullrequest:comment_created' &&
body.comment.content.raw.contains('/lgtm')
Wird ausgeführt, wenn eine Ausgabe mit dem angegebenen Label erstellt wird:
header['x-event-key'] == 'issue:created' &&
body.issue.kind == 'bug'
Filter
Mit Hilfe von Filtern können Benutzer Pull-Anfragen nach bestimmten Kriterien verfeinern. Das Filterfeld unterstützt derzeit die Angabe von Labels in Pull Requests, wodurch die Ausführung der Pipeline auf der Grundlage ihres Vorhandenseins oder Fehlens gesteuert wird. Sie löst jedoch keine Pipeline aus, wenn Kennzeichnungen hinzugefügt oder entfernt werden, sondern überprüft die Kennzeichnungen des PR, bevor sie die Ausführung der Pipeline zulässt.
Funktionsweise:
- Wenn ein PR-Ereignis eintritt (z. B. eine neue Übertragung), prüft die Pipeline die Labels auf dem PR.
- Wenn der PR die Bedingungen für die Kennzeichnung erfüllt (z. B. die Kennzeichnung "genehmigt" hat), läuft die Pipeline.
- Wenn der PR die Bedingungen für die Kennzeichnung nicht erfüllt, wird die Pipeline nicht ausgeführt.
Beispielkonfiguration
Die folgende Abbildung zeigt ein Beispiel, in dem der Auslöser für die Etiketten "genehmigt" und "geprüft" konfiguriert ist.
- Die PR-Pipeline wird nur ausgelöst, wenn beide Kennzeichnungen vorhanden sind.
- Fehlt eine der beiden Kennzeichnungen, wird die Pipeline nicht ausgeführt.

Überprüfung der Ereignis-Nutzlast
Wenn Sie CEL-Ausdrücke für die Ereignisfilterung schreiben, müssen Sie die Struktur und den Inhalt der Webhook-Nutzdaten verstehen, anhand derer der Ausdruck ausgewertet wird. Sie können die Nutzlast für einen vorhandenen Lauf auf der Seite mit den Details zum Pipeline-Lauf überprüfen.
Um die Nutzlast des Ereignisses zu sehen, gehen Sie auf die Detailseite des Pipeline-Laufs und klicken Sie auf Kontext anzeigen. Sie können die rohe Webhook-Nutzlast anzeigen, die den Pipeline-Lauf ausgelöst hat, und die relevanten Felder für Ihre CEL-Ausdrücke bestätigen, damit sie den gewünschten Bedingungen entsprechen.
Delivery Pipeline für Tekton mit der API erstellen
-
Rufen Sie ein IAM-Trägertoken ab.. Wenn Sie ein SDK verwenden, rufen Sie einen IAM-API-Schlüssel ab und legen Sie die Clientoptionen mithilfe von Umgebungsvariablen fest.
export CD_TEKTON_PIPELINE_APIKEY={api_key}
-
Bestimmen Sie die Region und die ID der Toolchain, zu der Sie die Toolintegration für Delivery Pipeline hinzufügen wollen.
-
Fügen Sie die Delivery Pipeline-Toolintegration zur Toolchain hinzu.
curl -X POST \ https://api.{region}.devops.cloud.ibm.com/toolchain/v2/toolchains/{toolchain_id}/tools \ -H 'Authorization: Bearer {iam_token}' \ -H 'Accept: application/json` \ -H 'Content-Type: application/json' \ -d '{ "tool_type_id": "pipeline", "parameters": { "name": "{tool_integration_name}", "type" : "tekton" } }'
const CdToolchainV2 = require('@ibm-cloud/continuous-delivery/cd-toolchain/v2'); ... (async () => { const toolchainService = CdToolchainV2.newInstance(); const pipelinePrototypeModel = { toolchainId: {toolchain_id}, toolTypeId: 'pipeline', name: {tool_integration_name}, type: "tekton" }; const pipelineTool = await toolchainService.createTool(pipelinePrototypeModel); })();
import ( "github.com/IBM/continuous-delivery-go-sdk/cdtoolchainv2" ) ... toolchainClientOptions := &cdtoolchainv2.CdToolchainV2Options{} toolchainClient, err := cdtoolchainv2.NewCdToolchainV2UsingExternalConfig(toolchainClientOptions) createPipelineToolOptions := toolchainClient.NewCreateToolOptions({toolchain_id}, "pipeline") createPipelineToolOptions.SetName({tool_integration_name}) createPipelineToolOptions.SetType("tekton") pipelineTool, response, err := toolchainClient.CreateTool(createPipelineToolOptions)
from ibm_continuous_delivery.cd_toolchain_v2 import CdToolchainV2 ... toolchain_service = CdToolchainV2.new_instance() pipeline_tool = toolchain_service.create_tool( name = {tool_integration_name}, toolchain_id = {toolchain_id}, tool_type_id = "pipeline", type = "tekton" )
import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.CdToolchain; import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.model.*; ... CdToolchain toolchainService = CdToolchain.newInstance(); CreateToolOptions createPipelineToolOptions = new CreateToolOptions.Builder() .name({tool_integration_name}) .toolchainId({toolchain_id}) .toolTypeId("pipeline") .type("tekton") .build(); Response<ToolchainToolPost> response = toolchainService.createTool(createPipelineToolOptions).execute(); ToolchainToolPost pipelineTool = response.getResult();
In der folgenden Tabelle werden alle im vorherigen Schritt verwendeten Variablen aufgelistet und beschrieben.
Variablen für das Hinzufügen des Delivery Pipeline Tools zur Integration mit der API Variable Beschreibung {region}
Die Region, in der sich die Toolchain befindet, z. B. us-south
.{tool_integration_name}
Ein Name für Ihre Toolintegration, z. B. ci-pipeline
.{toolchain_id}
Die ID der Toolchain, zu der die Toolintegration hinzugefügt wird {iam_token}
Ein gültiges IAM-Inhaber-Token. -
Konfigurieren Sie Delivery Pipeline für die Verwendung öffentlicher verwalteter Worker in den angegebenen Regionen.
curl -X POST \ https://api.{region}.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines \ -H 'Authorization: Bearer {iam_token}' \ -H 'Accept: application/json` \ -H 'Content-Type: application/json' \ -d '{ "id": "{pipeline_id}", "worker": { "id": "public" } }'
const CdTektonPipelineV2 = require('@ibm-cloud/continuous-delivery/cd-tekton-pipeline/v2'); ... (async () => { const tektonService = CdTektonPipelineV2.newInstance(); const workerIdentityModel = { id: 'public', }; const params = { id: {pipeline_id}, worker: workerIdentityModel, }; const res = await tektonService.createTektonPipeline(params); })();
import { "github.com/IBM/continuous-delivery-go-sdk/cdtektonpipelinev2" } ... cdTektonPipelineOptions := &cdtektonpipelinev2.CdTektonPipelineV2Options{} pipelineSvc, err = cdtektonpipelinev2.NewCdTektonPipelineV2UsingExternalConfig(cdTektonPipelineOptions) createTektonPipelineOptions := pipelineSvc.NewCreateTektonPipelineOptions( {pipeline_id} ) workerIdentityModel := &cdtektonpipelinev2.WorkerIdentity{ ID: core.StringPtr("public"), } createTektonPipelineOptions.SetWorker(workerIdentityModel) tektonPipeline, response, err := pipelineSvc.CreateTektonPipeline(createTektonPipelineOptions)
from ibm_continuous_delivery.cd_tekton_pipeline_v2 import CdTektonPipelineV2 ... pipeline_service = CdTektonPipelineV2.new_instance() worker_identity_model = { 'id': 'public', } response = pipeline_service.create_tekton_pipeline( id = {pipeline_id}, worker = worker_identity_model ) tekton_pipeline = response.get_result()
import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.CdTektonPipeline; import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.model.*; ... CdTektonPipeline pipelineSvc = CdTektonPipeline.newInstance(); WorkerIdentity workerIdentityModel = new WorkerIdentity.Builder() .id("public") .build(); CreateTektonPipelineOptions createTektonPipelineOptions = new CreateTektonPipelineOptions.Builder() .id({pipeline_id}) .worker(workerIdentityModel) .build(); Response<TektonPipeline> response = pipelineSvc.createTektonPipeline(createTektonPipelineOptions).execute(); TektonPipeline tektonPipeline = response.getResult();
In der folgenden Tabelle werden alle im vorherigen Schritt verwendeten Variablen aufgelistet und beschrieben.
Variablen für die Konfiguration der Delivery Pipeline mit der API Variable Beschreibung {region}
Die Region, in der sich die Toolchain befindet, z. B. us-south
.{pipeline_id}
Die ID der Pipeline, die vom vorherigen Schritt zurückgegeben wurde, in dem die Pipeline-Toolintegration erstellt wurde. {iam_token}
Ein gültiges IAM-Inhaber-Token.
Weitere Informationen über die Delivery Pipeline API finden Sie in den API Docs.
Delivery Pipeline für Tekton mit Terraform erstellen
-
Um das Terraform CLI zu installieren und das IBM Cloud Provider-Plugin für Terraform zu konfigurieren, folgen Sie dem Lernprogramm für Erste Schritte mit Terraform auf IBM Cloud®.
-
Erstellen Sie eine Terraform-Konfigurationsdatei mit dem Namen
main.tf
. Fügen Sie in dieser Datei die Konfiguration für die Erstellung einer Pipeline mit Hilfe der HashiCorp Configuration Language hinzu. Weitere Informationen zur Verwendung dieser Konfigurationssprache finden Sie in der Terraform-Dokumentation.Eine Pipeline muss zu einer Toolchain gehören. Sie können Toolchains auch mit Terraform erstellen.
Im folgenden Beispiel werden eine Toolchain und eine Pipeline mithilfe der angegebenen Terraform-Ressourcen erstellt.
data "ibm_resource_group" "group" { name = "default" } resource "ibm_cd_toolchain" "my_toolchain" { name = "terraform_toolchain" resource_group_id = data.ibm_resource_group.group.id } resource "ibm_cd_toolchain_tool_pipeline" "my_pipeline_tool" { parameters { name = "terraform-pipeline-integration" } toolchain_id = ibm_cd_toolchain.my_toolchain.id } resource "ibm_cd_tekton_pipeline" "my_tekton_pipeline" { worker { id = "public" } pipeline_id = ibm_cd_toolchain_tool_pipeline.my_pipeline_tool.tool_id }
Weitere Informationen zu den Ressourcen
ibm_cd_toolchain_tool_pipeline
undibm_cd_tekton_pipeline
finden Sie in den Argumentreferenzdetails in der Dokumentation zur Terraform-Registry. -
Initialisieren Sie bei Bedarf die Terraform-CLI.
terraform init
-
Erstellen Sie einen Terraform-Ausführungsplan. Dieser Plan fasst alle Aktionen zusammen, die zum Erstellen einer Toolchain ausgeführt werden müssen.
terraform plan
-
Wenden Sie den Terraform-Ausführungsplan an. Terraform führt alle erforderlichen Aktionen zum Erstellen der Toolchain aus.
terraform apply
Delivery Pipeline für Tekton anzeigen
Sie können eine Pipeline über die Konsolenbenutzerschnittstelle, mit der API oder mit Terraform anzeigen.
Delivery Pipeline über die Konsole anzeigen
Auf der Übersichtsseite von Tekton Delivery Pipeline wird eine leere Tabelle angezeigt, bis mindestens ein Auslöser hinzugefügt wurde. Nach Tekton-Pipeline-Ausführungen (entweder manuell oder als Ergebnis externer Ereignisse) werden in der
Tabelle Daten zu den letzten Ausführungen angezeigt, die jedem Auslöser in der Pipeline zugeordnet sind. Jede Zeile zeigt Informationen zu einem einzelnen Trigger und ein Diagramm der letzten Ausführungen an, die diesem Trigger zugeordnet
sind. Außerdem werden Informationen wie der Erfolg oder das Fehlschlagen dieser Ausführungen und die Zeit, zu der die letzte Ausführung erfolgte, angezeigt. Sie können auch Aktionen für jeden Auslöser ausführen: den Auslöser manuell ausführen,
als Favorit markieren, den Auslöser bearbeiten, aktivieren oder inaktivieren oder löschen. Sie können auch auf eines der Elemente im Diagramm klicken, um die Details dieser Einzelperson zu überprüfen PipelineRun
. Sie können
auch auf einen Triggernamen klicken, um die Seite PipelineRuns für alle PipelineRun
zu öffnen, die diesem Trigger zugeordnet sind. Zugehörige Informationen wie Status, Auslöser und Dauer jeder PipelineRun
sind ebenfalls
verfügbar.
Pipelineausführungen können die folgenden Status haben:
- Anstehend:
PipelineRun
wurde angefordert. - Aktiv:
PipelineRun
wird im Cluster ausgeführt. - Erfolgreich:
PipelineRun
wurde erfolgreich im Cluster ausgeführt. - Fehlgeschlagen:
PipelineRun
ist fehlgeschlagen. Suchen Sie in der Protokolldatei nach der Ausführung, um die Ursache zu bestimmen. - In der Warteschlange:
PipelineRun
wurde zur Verarbeitung akzeptiert und wird ausgeführt, sobald Workerkapazität verfügbar ist. - Wartestatus:
PipelineRun
befindet sich im Wartestatus vor der Aufnahme in die Warteschlange. - Abgebrochen:
PipelineRun
wurde vom System oder vom Benutzer abgebrochen. Das System bricht einePipelineRun
ab, wenn die Anzahl der wartenden Läufe die zulässige Grenze überschreitet. - Fehler:
PipelineRun
enthält Fehler, die die Anwendung für den Cluster verhindert haben. Weitere Informationen zur Fehlerursache finden Sie in den Ausführungsdetails.
Detaillierte Informationen zu einer ausgewählten Ausführung erhalten Sie, wenn Sie auf eine Zeile in der Tabelle klicken, um die Task
-Definition und die Schritte in jeder PipelineRun
-Definition anzuzeigen. Sie können
auch den Status, die Protokolle und die Details jeder Task
-Definition und jedes Schritts sowie den Gesamtstatus der Definition PipelineRun
anzeigen.
Der Aufbewahrungszeitraum für PipelineRuns und ihre Protokolle hängt von dem Plan ab, der für die Serviceinstanz Continuous Delivery ausgewählt ist. Tekton-Pipelines im Rahmen des Professional-Plans werden für ein Jahr beibehalten. Tekton-Pipelines
unter dem Lite-Plan werden 30 Tage lang aufbewahrt. Wenn Sie PipelineRuns
über den Aufbewahrungszeitraum hinaus beibehalten möchten, wählen Sie im Abschnitt PipelineRuns die Option Aktionen > Herunterladen**
aus, um eine ZIP-Datei herunterzuladen.
Delivery Pipeline mit der API anzeigen
-
Rufen Sie ein IAM-Trägertoken ab.. Wenn Sie ein SDK verwenden, rufen Sie einen IAM-API-Schlüssel ab und legen Sie die Clientoptionen mithilfe von Umgebungsvariablen fest.
export CD_TEKTON_PIPELINE_APIKEY={api_key}
-
Rufen Sie die Pipelinedaten ab.
curl -X GET \ https://api.{region}.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/{pipeline_id} \ -H 'Authorization: Bearer {iam_token}' \ -H 'Accept: application/json`
const CdTektonPipelineV2 = require('@ibm-cloud/continuous-delivery/cd-tekton-pipeline/v2'); ... (async () => { const pipelineSvc = CdTektonPipelineV2.newInstance(); const params = { id: {pipeline_id}, }; const res = await pipelineSvc.getTektonPipeline(params); })();
import { "github.com/IBM/continuous-delivery-go-sdk/cdtektonpipelinev2" } ... cdTektonPipelineOptions := &cdtektonpipelinev2.CdTektonPipelineV2Options{} pipelineSvc, err = cdtektonpipelinev2.NewCdTektonPipelineV2UsingExternalConfig(cdTektonPipelineOptions) getTektonPipelineOptions := pipelineSvc.NewGetTektonPipelineOptions( {pipeline_id} ) tektonPipeline, response, err := pipelineSvc.GetTektonPipeline(getTektonPipelineOptions)
from ibm_continuous_delivery.cd_tekton_pipeline_v2 import CdTektonPipelineV2 ... pipeline_service = CdTektonPipelineV2.new_instance() response = pipeline_service.get_tekton_pipeline( id = {pipeline_id} ) tekton_pipeline = response.get_result()
import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.CdTektonPipeline; import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.model.*; ... CdTektonPipeline pipelineSvc = CdTektonPipeline.newInstance(); GetTektonPipelineOptions getTektonPipelineOptions = new GetTektonPipelineOptions.Builder() .id({pipeline_id}) .build(); Response<TektonPipeline> response = pipelineSvc.getTektonPipeline(getTektonPipelineOptions).execute(); TektonPipeline tektonPipeline = response.getResult();
In der folgenden Tabelle werden alle im vorherigen Schritt verwendeten Variablen aufgelistet und beschrieben.
Variable | Beschreibung |
---|---|
{region} |
Die Region, in der die Pipeline liegt, z. B. us-south . |
{pipeline_id} |
Die ID der Pipeline, die Sie anzeigen möchten. |
{iam_token} |
Ein gültiges IAM-Inhaber-Token. |
Delivery Pipeline mit Terraform anzeigen
-
Suchen Sie die Terraform-Datei (z. B.
main.tf
), die den Blockresource
für die vorhandene Pipeline enthält. -
Fügen Sie einen
output
-Block zur Terraform-Datei hinzu, wenn er noch keinen Block enthält.Die
resource
im folgenden Beispiel beschreibt eine vorhandene Pipeline. Der Blockoutput
weist Terraform an, die Attribute der angegebenen Ressource auszugeben.data "ibm_resource_group" "group" { name = "default" } resource "ibm_cd_toolchain" "my_toolchain" { name = "terraform_toolchain" resource_group_id = data.ibm_resource_group.group.id } resource "ibm_cd_toolchain_tool_pipeline" "my_pipeline_tool" { parameters { name = "terraform-pipeline-integration" } toolchain_id = ibm_cd_toolchain.my_toolchain.id } resource "ibm_cd_tekton_pipeline" "my_tekton_pipeline" { worker { id = "public" } pipeline_id = ibm_cd_toolchain_tool_pipeline.my_pipeline_tool.tool_id } output "my_tekton_pipeline_attributes" { value = ibm_cd_tekton_pipeline.my_tekton_pipeline }
Weitere Informationen zu den Ressourcen
ibm_cd_toolchain_tool_pipeline
undibm_cd_tekton_pipeline
finden Sie in den Argumentreferenzdetails in der Dokumentation zur Terraform-Registry. -
Initialisieren Sie bei Bedarf die Terraform-CLI.
terraform init
-
Wenden Sie den Terraform-Ausführungsplan mit der Option
refresh-only
an. Terraform aktualisiert seinen Status und zeigt die Attribute der Pipeline-Ressource an.terraform apply -refresh-only -auto-approve
Löschen einer Delivery Pipeline mit der API
-
Rufen Sie ein IAM-Trägertoken ab.. Wenn Sie ein SDK verwenden, rufen Sie einen IAM-API-Schlüssel ab und legen Sie die Clientoptionen mithilfe von Umgebungsvariablen fest.
export CD_TEKTON_PIPELINE_APIKEY={api_key}
-
Bestimmen Sie die Region und ID der Toolchain, der Sie die DevOps Insights-Toolintegration hinzufügen wollen.
-
Löschen Sie die Pipeline.
curl -X DELETE \ https://api.{region}.devops.cloud.ibm.com/toolchain/v2/toolchains/{toolchain_id}/tools/{pipeline_id} \ -H 'Authorization: Bearer {iam_token}'
const CdTektonPipelineV2 = require('@ibm-cloud/continuous-delivery/cd-tekton-pipeline/v2'); ... (async () => { const pipelineSvc = CdTektonPipelineV2.newInstance(); const params = { id: {pipeline_id}, }; const res = await pipelineSvc.deleteTektonPipeline(params); })();
import { "github.com/IBM/continuous-delivery-go-sdk/cdtektonpipelinev2" } ... cdTektonPipelineOptions := &cdtektonpipelinev2.CdTektonPipelineV2Options{} pipelineSvc, err = cdtektonpipelinev2.NewCdTektonPipelineV2UsingExternalConfig(cdTektonPipelineOptions) deleteTektonPipelineOptions := pipelineSvc.NewDeleteTektonPipelineOptions( {pipeline_id} ) response, err := pipelineSvc.DeleteTektonPipeline(deleteTektonPipelineOptions)
from ibm_continuous_delivery.cd_tekton_pipeline_v2 import CdTektonPipelineV2 ... pipeline_service = CdTektonPipelineV2.new_instance() response = pipeline_service.delete_tekton_pipeline( id={pipeline_id} )
import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.CdTektonPipeline; import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.model.*; ... CdTektonPipeline pipelineSvc = CdTektonPipeline.newInstance(); DeleteTektonPipelineOptions deleteTektonPipelineOptions = new DeleteTektonPipelineOptions.Builder() .id({pipeline_id}) .build(); Response<Void> response = pipelineSvc.deleteTektonPipeline(deleteTektonPipelineOptions).execute();
In der folgenden Tabelle werden alle im vorherigen Schritt verwendeten Variablen aufgelistet und beschrieben.
Variable | Beschreibung |
---|---|
{region} |
Die Region, in der sich die Toolchain befindet, z. B. us-south . |
{toolchain_id} |
Die ID der Toolchain, die die zu löschende Pipeline enthält. |
{pipeline_id} |
Die ID der Pipeline, die Sie löschen möchten. |
{iam_token} |
Ein gültiges IAM-Inhaber-Token. |
Auslöser verwenden
Sie können Pipelines entweder über die Web-UI oder über einen Befehlszeilen-/API-Aufruf auslösen. Dies wird in der Regel für Pipelines wie CI-, CD- oder CC-Pipelines verwendet.
Auslösen der Pipeline über die Befehlszeile oder API
Sie können eine Pipeline über die Befehlszeile auslösen, indem Sie entweder die IBM Cloud CLI verwenden oder einen direkten API-Aufruf mit curl
tätigen.
IBM Cloud-Befehlszeilenschnittstelle verwenden
Sie können die Pipeline über die IBM Cloud CLI auslösen. Weitere Informationen zu CLI-Befehlen finden Sie in den IBM Cloud CLI-Dokumenten.
- Bei IBM Cloud anmelden
ibmcloud login --sso
- Manuelles Auslösen der Pipeline
ibmcloud dev tekton-trigger run <pipeline_id> --trigger-name "<trigger_name>"
Nachdem Sie pipeline_id
und trigger_name
in dem Befehl ersetzt haben, führen Sie ihn aus, um die Pipeline zu starten. Bei Erfolg zeigt die Ausgabe an, dass die Pipeline gestartet wurde, und enthält Details wie die
folgenden:
Pipeline wurde erfolgreich gestartet.
- Lauf-ID : ruekhg-eifjkvr-kjf-rkvj
- Auslöser : CC Manueller Auslöser
- Status: anhängig
Sie können dann überprüfen, ob Ihre Pipeline ausgelöst wurde, indem Sie Ihre entsprechende Toolchain in der Benutzeroberfläche öffnen.
Verwendung von curl
zum Auslösen der Pipeline über API
Sie können die Pipeline direkt über die API mit curl
auslösen. Weitere Informationen zum Auslösen von Tekton-Pipelines über die API finden Sie in den IBM Cloud API Docs/
CD Tekton Pipeline.
Authentifizierungsverfahren
-
Wenn Sie noch keinen API-Schlüssel haben, gehen Sie zu IBM Cloud API Keys, um einen zu generieren.
-
Sobald Sie Ihren API-Schlüssel haben, erzeugen Sie ein IAM-Token mit dem folgenden Befehl
curl
:curl -X POST 'https://iam.cloud.ibm.com/identity/token' \ -H 'Content-Type:application/x-www-form-urlencoded' \ -H 'Accept:application/json' \ -d 'grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey=<API_KEY>'
-
Ersetzen Sie <API_KEY> durch Ihren generierten API-Schlüssel.
-
Sobald Sie das IAM-Token haben, verwenden Sie es, um die folgende Anfrage für den Zugriff auf Ihre Pipeline zu authentifizieren:
curl -L --request GET 'https://api.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/<PIPELINE_ID>' \ --header 'Authorization: Bearer <IAM_TOKEN_VALUE>'
-
Nach der Authentifizierung lösen Sie die Pipeline mit dem folgenden Befehl
curl
aus:curl -i -X POST \ -H "Authorization: Bearer <IAM_token>" \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ --data '{ "trigger": { "name": "CC Manual Trigger", "properties": { "pipeline-debug": "false" } } }' \ "https://api.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/<pipeline_id>/pipeline_runs"
-
Die Option
-i
sorgt dafür, dass HTTP Antwort-Header in die Ausgabe aufgenommen werden, so dass Sie im Falle von Fehlern den HTTP Statuscode sehen können. -
Sie können alle Umgebungseigenschaften, die für die Pipeline erforderlich sind, innerhalb der
--data
Nutzlast hinzufügen. Weitere Informationen zum Hinzufügen von Eigenschaften finden Sie in diesem IBM Cloud API Docs/ CD Tekton Pipeline. -
Die Ausgabe sieht ähnlich aus wie die folgende, wenn die Pipeline ausgelöst wird:
-
Die Antwort HTTP zeigt den Status
201 Created
an und bestätigt damit, dass die Anfrage für den Pipeline-Trigger angenommen wurde. -
Eine
location
Kopfzeile verweist auf die URL des ausgelösten Pipelinelaufs. -
Sie sehen Metadaten wie z. B.:
pipeline_id
status
(z. B."pending"
)trigger
name (z. B."Manual CD Trigger"
)run_id
(eindeutige ID für den ausgelösten Lauf)- Eine vollständige URL, um den Lauf in der Benutzeroberfläche anzuzeigen.
-
Dies bestätigt, dass die Pipeline erfolgreich ausgelöst wurde. Sie können nun zum Pipeline-Abschnitt Ihrer Toolchain in der Benutzeroberfläche IBM Cloud navigieren, um den Status und die Protokolle anzuzeigen.
-
-
Wenn der Befehl erfolgreich ausgeführt wird, wird die Pipeline ausgelöst. Nach der Auslösung enthält die Antwort Einzelheiten über den Pipeline-Lauf.
{{site.data.keyword.deliverypipeline}} mit Terraform löschen
-
Suchen Sie die Terraform-Datei (z. B.
main.tf
), die den Blockresource
für die vorhandene Pipeline enthält.Die
resource
im folgenden Beispiel beschreibt eine vorhandene Pipeline.data "ibm_resource_group" "group" { name = "default" } resource "ibm_cd_toolchain" "my_toolchain" { name = "terraform_toolchain" resource_group_id = data.ibm_resource_group.group.id } resource "ibm_cd_toolchain_tool_pipeline" "my_pipeline_tool" { parameters { name = "terraform-pipeline-integration" } toolchain_id = ibm_cd_toolchain.my_toolchain.id } resource "ibm_cd_tekton_pipeline" "my_tekton_pipeline" { worker { id = "public" } pipeline_id = ibm_cd_toolchain_tool_pipeline.my_pipeline_tool.tool_id }
-
Entfernen Sie die Blöcke
ibm_cd_toolchain_tool_pipeline
undibm_cd_tekton_pipeline
resource
aus Ihrer Terraform-Datei. -
Initialisieren Sie bei Bedarf die Terraform-CLI.
terraform init
-
Erstellen Sie einen Terraform-Ausführungsplan. Dieser Plan fasst alle Aktionen zusammen, die ausgeführt werden müssen, um die Pipeline zu löschen.
terraform plan
-
Wenden Sie den Terraform-Ausführungsplan an. Terraform führt alle erforderlichen Aktionen zum Löschen der Pipeline aus.
terraform apply
Details für einen TaskRun-Pod anzeigen
Um Informationen über den zugrunde liegenden Kubernetes-Pod für einen bestimmten TaskRun
anzuzeigen, klicken Sie auf den Namen Task
und dann auf Pod.
Sie können die Details für den Pod und alle zugehörigen Ereignisse anzeigen, die vom Worker gemeldet wurden. Diese Informationen können Ihnen dabei helfen, bestimmte Fehler zu beheben, oder festzustellen, wo Zeit während eines Testlaufs aufgewendet wird.
Weitere Informationen zu Tekton-Pipelines und -Ressourcen
Weitere Informationen über Tekton-Pipelines finden Sie in den Artikeln Tekton: A Modern Approach to Continuous Delivery und IBM Cloud Continuous Delivery Tekton Pipelines Tools and Resources Artikel.
Weitere Informationen zu den Tekton-Aufgaben, auf die Sie in Ihren Pipelines verweisen können, finden Sie im Open Toolchain Tekton-Katalog. Dieses GitHub-Repository enthält eine Reihe von Tasks, die Sie in Ihren Tekton-Pipelines wiederverwenden können.