Auslösen einer Stufe durch Verwendung asynchroner Teilpipelines

Sie können jede Stufe auslösen, die der Konfigurationsdatei .pipeline-config.yaml hinzugefügt wurde, indem Sie asynchrone Teilpipelines verwenden. Sie müssen diese Stufen nicht inline in die Pipeline einfügen und die Pipeline nicht ändern.

Siehe den folgenden Beispielcode:

setup:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
  script: |
    #!/usr/bin/env bash

    source "${ONE_PIPELINE_PATH}"/tools/trigger-task
    set_env "variable-for-my-custom-task" "foo_bar"
    export_env "variable-for-my-custom-task"
    trigger-task "my-custom-task"

my-custom-task:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
  script: |
    #!/usr/bin/env bash
    if [[ "$PIPELINE_DEBUG" == 1 ]]; then
      trap env EXIT
      env
      set -x
    fi
    printf "Test custom stage to trigger async"
    list_repos
    list_artifacts
    get_env "variable-for-my-custom-task"

Zum Auslösen der Stufe wird ein Webhook-Trigger mit einem Webhook-Geheimnis erstellt. Das Webhook-Geheimnis ist in den Pipeline-Parametern und in den Eigenschaften von Subpipeline Webhook Trigger unter subpipeline-webhook-token zu finden. Weitere Informationen zum Aktualisieren des Werts von subpipeline-webhook-token finden Sie unter Aktualisieren der asynchronen Stage-Webhooks.

Der neu ausgelöste Pipelinename ist der Stufenname (z. B. my-custom-task). Stellen Sie daher sicher, dass der Stufenname ein gültiger Pipelinelaufname ist. Der Stufenname wird verwendet, um den Namen oder die ID auf einer Kubernetes Ressource zu erstellen. Objektnamen und IDs in Kubernetes müssen RFC 1123 oder RFC 1035 entsprechen:

  • Sie dürfen maximal 63 Zeichen enthalten.
  • Sie dürfen nur alphanumerische Kleinbuchstaben oder den Bindestrich "-" enthalten.
  • Beginnen Sie mit einem alphanumerischen Zeichen.
  • Endet mit einem alphanumerischen Zeichen.

Übergabe von Daten an die asynchrone Pipeline

Sie können Variablen übergeben, die für die Ausführung der Stufe erforderlich sind, und Sie können pipelinectl für diese Zwecke verwenden.

Sie können Daten zwischen zwei Pipelines weiterleiten, indem Sie die folgenden Schritte ausführen:

  1. Verwenden Sie set_env, um eine Variable zu speichern, bevor Sie die asynchrone Pipeline auslösen. Beachten Sie, dass dies in der Pipeline vor der Auslösestufe geschehen kann. Sie brauchen set_env nicht zweimal zu verwenden.
  2. Markieren Sie die Variable mit export_env, um sie für den asynchronen Pipelinelauf zu exportieren.
  3. Jede Variable, die für den Export markiert ist, ist durch die Verwendung von get_env in der asynchronen Pipeline verfügbar.
set_env <variable-name> <variable-value>
export_env <variable-name>
get_env <variable-name>

Nur die markierten Variablen sind in der asynchronen Pipeline verfügbar. Nicht alles kann exportiert werden, da die Daten möglicherweise zu umfangreich sind oder sensible Daten enthalten.

Asynchronen Pipeline-Befehl auslösen

Verwenden Sie den folgenden Befehl, um eine Stufe auszulösen:

trigger-task <stage-name>

Beispielcode

setup:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
  script: |
    #!/usr/bin/env bash

    source "${ONE_PIPELINE_PATH}"/tools/trigger-task
    set_env "variable-for-my-custom-task" "foo_bar"
    export_env "variable-for-my-custom-task"
    trigger-task "my-custom-task"

Mit diesem Befehl wird die Aufgabe aus der yaml-Konfiguration der Pipeline ausgelöst. Beispiel: trigger-task owasp-zap.

Was in der ausgelösten Pipeline zugänglich ist

Alle Repositorys und Artefakte, die in der vorherigen Pipeline gespeichert und exportiert wurden (unter Verwendung von set_env von pipelinectl und dem Tool export_env ) in der vorherigen Pipeline gespeichert und exportiert wurden, sind auch in der neuen ausgelösten asynchronen Pipeline verfügbar. Repositories werden mit der Übergabe in der vorherigen Pipeline in dieselben arbeitsbereichsbezogenen Ordner geklont. Die Übergabe von Repositories muss in pipelinectl gespeichert werden, damit die Pipeline denselben Zustand des Repositories klonen kann.

Um zu Repositories und Artefakten zu gelangen, verwenden Sie list_repos und list_artifacts. Sie können alle Artefakte, die gebaut wurden, und alle Repositorys, die geklont wurden, abrufen, Sie müssen sie nur in pipelinectl.

Nicht verfügbar Es sind keine Änderungen am Arbeitsbereich verfügbar, die in früheren Aufgaben im auslösenden Pipeline-Lauf vorgenommen wurden (z. B. npm install), da wir den gesamten Arbeitsbereich nicht an den neuen ausgelösten Pipeline-Lauf übergeben können.

Abfrage des Status der ausgelösten Pipeline

API-Curl-Aufruf

 while [ "$STATE" = "running" -o "$STATE" = "waiting" -o "$STATE" = "queued" -o "$STATE" = "pending" ]; do
            PIPELINE_STATUS=$(curl -s -k -X GET \
            --header "Authorization: Bearer $IAM_ACCESS_TOKEN" \
            --header "Accept: application/json" \
            --header "Content-Type: application/json" \
            $CD_PIPELINE_RUN_URL)
            STATE=$(echo $PIPELINE_STATUS | jq -r '.status .state')
            echo $STATE
            sleep 10
 done

ibmcloud cli-Aufruf

ibmcloud dev tekton-pipelinerun [pipelineID] --run-id [pipelinerunID] [--output JSON]
ibmcloud dev tekton-pipelinerun ls [pipelineID]

Weitere Informationen finden Sie unter dem Befehl IBM Cloud CLI(tekton-pipelinerun).

Weitere Informationen zum Auslösen von Pipelines mithilfe der CLI finden Sie unter Verwenden von Auslösern