Déclencher une étape en utilisant des sous-pipelines asynchrones

Vous pouvez déclencher n'importe quelle étape ajoutée au fichier de configuration de .pipeline-config.yaml en utilisant des sous-pipelines asynchrones. Il n'est pas nécessaire d'ajouter ces étapes en ligne dans le pipeline, ni de modifier le pipeline.

Reportez-vous à l'exemple de code suivant :

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"

Pour déclencher l'étape, un déclencheur webhook est créé avec un secret webhook. Le secret du webhook se trouve dans les paramètres du pipeline et dans les propriétés de Subpipeline Webhook Trigger sous la forme subpipeline-webhook-token. Pour plus d'informations sur la mise à jour de la valeur de subpipeline-webhook-token, voir Mise à jour des webhooks de l'étape asynchrone.

Le nom du pipeline nouvellement déclenché est le nom de l'étape (par exemple my-custom-task), assurez-vous donc que le nom de l'étape est un nom d'exécution de pipeline valide. Le nom d'étape est utilisé pour créer le nom ou l'identifiant d'une ressource Kubernetes. Les noms d'objets et les ID dans Kubernetes doivent être conformes à la RFC 1123 ou à la RFC 1035:

  • Contient un maximum de 63 caractères.
  • Ne contenir que des caractères alphanumériques minuscules ou le trait d'union "-".
  • Commencez par un caractère alphanumérique.
  • Terminer par un caractère alphanumérique.

Transmettre des données à un pipeline asynchrone

Vous pouvez passer des variables nécessaires à l'exécution de la scène, et vous pouvez utiliser pipelinectl pour cela.

Vous pouvez transférer des données entre deux pipelines en suivant les étapes suivantes :

  1. Utilisez set_env pour enregistrer une variable avant de déclencher le pipeline asynchrone. Notez que cela peut se produire dans le pipeline avant l'étape de déclenchement. Il n'est pas nécessaire d'utiliser set_env deux fois.
  2. Marquez la variable avec export_env pour l'exporter pour l'exécution du pipeline asynchrone.
  3. Toute variable marquée pour l'exportation est disponible en utilisant get_env dans le pipeline asynchrone.
set_env <variable-name> <variable-value>
export_env <variable-name>
get_env <variable-name>

Seules les variables marquées sont disponibles dans le pipeline asynchrone. Tout ne peut pas être exporté car les données peuvent être trop importantes ou contenir des données sensibles.

Déclencher une commande de pipeline asynchrone

La commande suivante permet de déclencher une étape :

trigger-task <stage-name>

Exemple de code

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"

Cette commande déclenche la tâche à partir de la configuration yaml du pipeline. Par exemple, trigger-task owasp-zap.

Ce qui est accessible dans le pipeline déclenché

Chaque référentiel et artefact qui sont sauvegardés et exportés (en utilisant set_env de pipelinectl et l'outil export_env ) dans le pipeline précédent sont également disponibles dans le nouveau pipeline asynchrone déclenché. Les dépôts sont clonés avec le commit du pipeline précédent dans les mêmes dossiers relatifs à l'espace de travail. Le commit des dépôts doit être sauvegardé dans pipelinectl pour que le pipeline puisse cloner le même état du dépôt.

Pour accéder aux référentiels et aux artefacts, utiliser list_repos et list_artifacts. Vous pouvez obtenir tous les artefacts qui ont été construits et tous les dépôts qui ont été clonés, mais vous devez les enregistrer dans le fichier pipelinectl.

Non disponible Il n'est pas possible de modifier l'espace de travail qui a été fait dans les tâches précédentes de l'exécution du pipeline de déclenchement (par exemple, npm install) parce que nous ne pouvons pas passer l'ensemble de l'espace de travail dans la nouvelle exécution du pipeline de déclenchement.

Comment interroger l'état d'un pipeline déclenché

Appel curl de l'API

 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

appel ibmcloud cli

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

Pour plus d'informations, voir la commande CLI IBM Cloud(tekton-pipelinerun).

Pour plus d'informations sur le déclenchement de pipelines à l'aide de l'interface de gestion, voir Utilisation des déclencheurs