Attivare una fase utilizzando le sottopipline async

È possibile innescare qualsiasi fase aggiunta al file di configurazione .pipeline-config.yaml utilizzando le sottopipline async. Non è necessario aggiungere queste fasi in linea alla pipeline e non è necessario modificare la pipeline.

Si veda il seguente esempio di codice:

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"

Per attivare lo stage, viene creato un trigger webhook con un segreto webhook. Il segreto del webhook si trova nei parametri della pipeline e nel Subpipeline Webhook Trigger le proprietà di come subpipeline-webhook-token. Per ulteriori informazioni sull'aggiornamento del valore di subpipeline-webhook-token, vedere Aggiornamento degli async stage webhooks.

Il nome della pipeline appena attivata è il nome dello stage (ad esempio, my-custom-task), quindi assicurarsi che il nome dello stage sia un nome di esecuzione della pipeline valido. Il nome dello stage viene usato per creare il nome o l'ID di una risorsa Kubernetes. I nomi e gli ID degli oggetti in Kubernetes devono essere conformi a RFC 1123 o RFC 1035:

  • Contiene un massimo di 63 caratteri.
  • Contenere solo caratteri alfanumerici minuscoli o il carattere trattino "-".
  • Iniziare con un carattere alfanumerico.
  • Terminare con un carattere alfanumerico.

Passare i dati alla pipeline asincrona

Si possono passare le variabili necessarie per l'esecuzione dello stage e si può usare il metodo pipelinectl per questo.

È possibile passare i dati tra due pipeline seguendo i seguenti passaggi:

  1. Utilizzare set_env per salvare una variabile prima di attivare la pipeline asincrona. Si noti che ciò può avvenire nella pipeline prima della fase di attivazione. Non è necessario usare set_env due volte.
  2. Contrassegnare la variabile con export_env per esportarla per l'esecuzione della pipeline async.
  3. Qualsiasi variabile contrassegnata per l'esportazione è disponibile utilizzando get_env nella pipeline async.
set_env <variable-name> <variable-value>
export_env <variable-name>
get_env <variable-name>

Solo le variabili contrassegnate sono disponibili nella pipeline async. Non tutto può essere esportato perché i dati potrebbero essere troppo consistenti o contenere dati sensibili.

Comando di attivazione della pipeline async

Utilizzate il seguente comando per attivare uno stadio:

trigger-task <stage-name>

Codice di esempio

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"

Questo comando attiva il task dalla configurazione yaml della pipeline. Ad esempio, trigger-task owasp-zap.

Cosa è accessibile nella pipeline attivata

Tutti i repository e gli artefatti salvati ed esportati (usando set_env da pipelinectl e lo strumento export_env ) nella pipeline precedente sono disponibili anche nella nuova pipeline asincrona attivata. I repository vengono clonati con il commit nella pipeline precedente nelle stesse cartelle relative allo spazio di lavoro. Il commit dei repository deve essere salvato in pipelinectl perché la pipeline possa clonare lo stesso stato del repository.

Per accedere ai repository e agli artefatti si usano i comandi list_repos e list_artifacts. È possibile ottenere tutti gli artefatti che sono stati costruiti e tutti i repository che sono stati clonati, solo che è necessario salvarli in pipelinectl.

Non disponibile Non sono disponibili le modifiche apportate all'area di lavoro nelle attività precedenti dell'esecuzione della pipeline di attivazione (per esempio, npm install), perché non è possibile passare l'intera area di lavoro nella nuova esecuzione della pipeline di attivazione.

Come interrogare lo stato della pipeline attivata

Chiamata API curl

 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

chiamata ibmcloud cli

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

Per ulteriori informazioni, consultare il comando IBM Cloud CLI(tekton-pipelinerun).

Per ulteriori informazioni sull'attivazione delle pipeline tramite la CLI, vedere Utilizzo dei trigger