Mit Tekton-Pipelines arbeiten

Delivery Pipeline für Tekton über die Konsole konfigurieren

1. Klicken Sie auf der Übersichtsseite Ihrer Toolchain auf der Karte „Bereitstellungspipelines“ auf die Schaltfläche Delivery Pipeline, um die Übersichtsseite der Tekton- Delivery Pipeline-Pipeline zu öffnen.

2. 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.

3. 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.

4. 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 Ressource PipelineRun 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.

5. Klicken Sie auf Speichern.

6. Klicken Sie auf der Seite „Pipeline-Übersicht“ auf „Hinzufügen“, um einen Trigger zu erstellen, wählen Sie den Typ des hinzuzufügenden Triggers aus und ordnen Sie den Trigger einem Ereignis-Listener zu. Die Liste der verfügbaren Ereignislistener enthält die Listener, die im Pipeline-Code-Repository definiert sind.

   Trigger basieren auf Tekton-Triggerdefinitionen. Git Repo-Trigger nutzen den ihnen zugeordneten Ereignis-Listener, um Informationen aus der Nutzlast des eingehenden Ereignisses zu extrahieren und Ressourcen unter Kubernetes 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 beispielsweise die Obergrenze auf 1 festgelegt ist, wird jeweils nur ein Pipeline-Lauf für diesen Trigger ausgeführt, während alle anderen im Status „Warten“ in die Warteschlange gestellt werden. Es werden maximal 20 Läufe (5, wenn Sie von „ IBM “ verwaltete Worker verwenden) im Wartestatus in die Warteschlange gestellt, bevor nachfolgende Anfragen automatisch abgebrochen werden. Standardmäßig sind alle zeitgesteuerten Trigger bei der Verwendung von „ IBM Managed Workers“ auf eine gleichzeitige Ausführung beschränkt.

   Wenn ein Auslöser sein Limit für gleichzeitige Läufe überschreitet, werden neue Pipelineläufe in den Zustand "Warten" versetzt, bis Kapazität verfügbar wird. Falls gewünscht, kann dieses Verhalten so geändert werden, dass nur der jüngste Lauf im Zustand "Warten" sein kann und andere solche Läufe automatisch abgebrochen werden. Dies kann beispielsweise für Git Trigger nützlich sein, wenn Sie nur den neuesten Commit erstellen möchten, wenn mehrere Läufe in einem kurzen Zeitrahmen ausgelöst werden. Um diese Funktion zu aktivieren, ist ein "Limit to one waiting run" Toggle im Trigger-Konfigurationspanel verfügbar, der auch über die API mit der Eigenschaft limit_waiting_runs gesetzt werden kann (siehe API-Dokumente ). Beachten Sie, dass diese Einstellung nur für Läufe im Status "Warten" gilt und keine Auswirkungen auf aktive Läufe hat.

   Manuelle 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 einem festgelegten Zeitpunkt ausgeführt, der durch den CRON-Wert definiert ist. Der CRON-Ausdruck für zeitgesteuerte Auslöser basiert auf der UNIX-crontab-Syntax und besteht aus einer Abfolge von fünf Zeit- und Datumsfeldern: minute, hour, day of the month, month und day of the week. Diese Felder werden durch Leerzeichen im Format X 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:

  ![Generisches](images/pipeline_tekton_generic_webhook.png){: caption="" 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, Release-Ereignisse und GitHub Merge-Queue-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.

   header['x-github-event'] == 'pull_request' &&
      (body.action == 'opened' || body.action == 'synchronize') &&
      body.pull_request.base.ref == 'main'

   header['x-github-event'] == 'push' && body.ref == 'refs/heads/main'

   header['x-github-event'] == 'push' &&
      body.ref == 'refs/heads/main' &&
      !body.head_commit.message.contains("skip run")

   header['x-github-event'] == 'issue_comment' &&
      body.action == 'created' && has(body.issue.pull_request) &&
      body.comment.body.contains('/lgtm')

   header['x-github-event'] == 'issues' &&
      body.action == 'opened' &&
      body.issue.labels.exists(label, label.name == 'urgent')

   header['x-gitlab-event'] == 'Merge Request Hook' &&
      (body.object_attributes.action == 'open' || body.object_attributes.action == 'update') &&
      body.object_attributes.target_branch == 'main'

   header['x-gitlab-event'] == 'Push Hook' && body.ref == 'refs/heads/main'

   header['x-gitlab-event'] == 'Push Hook' &&
      body.ref == 'refs/heads/main' &&
      !body.object_attributes.last_commit.message("skip run")

   header['x-gitlab-event'] == 'Note Hook' &&
      body.object_attributes.noteable_type == 'MergeRequest' &&
      body.object_attributes.action == 'create' &&
      body.object_attributes.note.contains('/lgtm')

   header['x-gitlab-event'] == 'Issue Hook' &&
      (body.object_attributes.action == 'open') &&
      body.object_attributes.labels.exists(label, label.name == 'urgent')

   (header['x-event-key'] == 'pullrequest:created' || header['x-event-key'] == 'pullrequest:updated') &&
       body.pullrequest.destination.branch.name == 'main'

   header['x-event-key'] == 'repo:push' && body.push.changes[0].new.name == 'main'

   header['x-event-key'] == 'repo:push' &&
      body.push.changes[0].new.name == 'main' &&
      !body.push.changes[0].commits[0].message("skip run")

   header['x-event-key'] == 'pullrequest:comment_created' &&
      body.comment.content.raw.contains('/lgtm')

   header['x-event-key'] == 'issue:created' &&
      body.issue.kind == 'bug'

Löschen einer Toolchain über die Konsolenoberfläche

1. Klicken Sie in der Konsole IBM Cloud auf das Menü > Platform Automation > Toolchains.
2. Klicken Sie auf der Seite 'Toolchains' auf eine Toolchain, um die zugehörige Übersichtsseite zu öffnen. Klicken Sie alternativ auf der Seite mit den App-Details in Ihrer App auf den Toolchainnamen.
3. Suchen Sie im Abschnitt "Delivery Pipelines" die Pipeline, die Sie löschen möchten.
4. Klicken Sie auf das Menüsymbol für diese Pipeline und dann auf die Option Löschen.
5. Bestätigen Sie den Löschvorgang, indem Sie im Dialogfeld auf „Löschen“ klicken.

Delivery Pipeline s über die API löschen

1. 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}
   

2. Bestimmen Sie die Region und ID der Toolchain, der Sie die DevOps Insights-Toolintegration hinzufügen wollen.

3. 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.

Delivery Pipeline mit Terraform löschen

1. Suchen Sie die Terraform-Datei (z. B. main.tf), die den Block resource 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
   }
   

2. Entfernen Sie die Blöcke ibm_cd_toolchain_tool_pipeline und ibm_cd_tekton_pipeline resource aus Ihrer Terraform-Datei.

3. Initialisieren Sie bei Bedarf die Terraform-CLI.

   terraform init
   

4. 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
   

5. Den Terraform-Ausführungsplan anwenden. Terraform führt alle erforderlichen Aktionen zum Löschen der Pipeline aus.

   terraform apply
   

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.