Activación de una etapa mediante subprocesos asíncronos

Puede desencadenar cualquier etapa que se añada al archivo de configuración .pipeline-config.yaml utilizando subpipelines asíncronos. No es necesario añadir esas etapas en línea a la tubería, y no es necesario modificar la tubería.

Consulte el código de ejemplo siguiente:

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"

Para activar la etapa, se crea un activador webhook con un secreto webhook. El secreto del webhook se encuentra en los parámetros del Pipeline y en las propiedades de Subpipeline Webhook Trigger como subpipeline-webhook-token. Para obtener más información sobre la actualización del valor de subpipeline-webhook-token, consulte Actualización de los webhooks de la etapa asíncrona.

El nombre de la tubería recién activada es el nombre de la etapa (por ejemplo, my-custom-task), así que asegúrese de que el nombre de la etapa es un nombre de ejecución de tubería válido. El nombre del escenario se utiliza para crear el nombre o ID en un recurso Kubernetes. Los nombres e ID de objetos en Kubernetes deben seguir las normas RFC 1123 o RFC 1035:

  • Contener un máximo de 63 caracteres.
  • Contener sólo caracteres alfanuméricos en minúsculas o el carácter guión "-".
  • Comience con un carácter alfanumérico.
  • Termina con un carácter alfanumérico.

Pasar datos al pipeline asíncrono

Puede pasar variables que se necesitan para ejecutar la etapa, y puede utilizar pipelinectl para ello.

Puede pasar datos entre dos pipelines siguiendo estos pasos:

  1. Utilice set_env para guardar una variable antes de activar el proceso asíncrono. Tenga en cuenta que esto puede ocurrir en la tubería antes de la etapa de activación. No es necesario utilizar set_env dos veces.
  2. Marque la variable con export_env para exportarla para la ejecución asíncrona del pipeline.
  3. Cualquier variable marcada para exportación está disponible utilizando get_env en el pipeline async.
set_env <variable-name> <variable-value>
export_env <variable-name>
get_env <variable-name>

Sólo las variables marcadas están disponibles en la canalización asíncrona. No todo puede exportarse porque los datos pueden ser demasiado voluminosos o contener datos sensibles.

Activar comando async pipeline

Utilice el siguiente comando para activar una etapa:

trigger-task <stage-name>

Código de ejemplo

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"

Este comando activa la tarea desde el yaml de configuración del pipeline. Por ejemplo, trigger-task owasp-zap.

A qué se puede acceder en la canalización activada

Todos los repositorios y artefactos guardados y exportados (utilizando set_env desde pipelinectl y la herramienta export_env ) en el proceso anterior también están disponibles en el nuevo proceso asíncrono activado. Los repositorios se clonan con la confirmación de la cadena anterior en las mismas carpetas relativas al espacio de trabajo. El commit de los repositorios debe guardarse en pipelinectl para que el pipeline pueda clonar el mismo estado de repositorio.

Para acceder a los repositorios y artefactos utilice list_repos y list_artifacts. Puedes obtener todos los artefactos que se construyeron y todos los repositorios que se clonaron sólo que debes guardarlos en pipelinectl.

No Disponible No está disponible cualquier cambio en el espacio de trabajo que se realiza en las tareas anteriores en la ejecución de la tubería de disparo (por ejemplo, npm install) porque no podemos pasar todo el espacio de trabajo en la nueva ejecución de la tubería de disparo.

Cómo consultar el estado de una canalización activada

Llamada curl a la 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

ibmcloud cli call

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

Para más información, consulte la página IBM Cloud Comando CLI(tekton-pipelinerun).

Para obtener más información sobre la activación de canalizaciones mediante la CLI, consulte Utilización de activadores