Acionamento de um estágio usando subpipelines assíncronos

Você pode acionar qualquer estágio adicionado ao arquivo de configuração .pipeline-config.yaml usando subpipelines assíncronos. Você não precisa adicionar esses estágios em linha ao pipeline e não precisa modificar o pipeline.

Veja o código de exemplo a seguir:

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 acionar o estágio, um acionador de webhook é criado com um segredo de webhook. O segredo do webhook é encontrado nos parâmetros do Pipeline e nas propriedades do Subpipeline Webhook Trigger como subpipeline-webhook-token. Para obter mais informações sobre a atualização do valor de subpipeline-webhook-token, consulte Atualização dos webhooks do estágio assíncrono.

O nome do pipeline acionado recentemente é o nome do estágio (por exemplo, my-custom-task), portanto, certifique-se de que o nome do estágio seja um nome de execução de pipeline válido. O nome do estágio é usado para criar o nome ou ID em um recurso Kubernetes. Os nomes e IDs de objetos em Kubernetes devem seguir a RFC 1123 ou a RFC 1035:

Contém um máximo de 63 caracteres.
Conter apenas caracteres alfanuméricos minúsculos ou o caractere de hífen '-'.
Comece com um caractere alfanumérico.
Termine com um caractere alfanumérico.

Passagem de dados para o pipeline assíncrono

Você pode passar variáveis que são necessárias para executar o estágio, e pode usar pipelinectl para isso.

Você pode passar dados entre dois pipelines seguindo estas etapas:

Use set_env para salvar uma variável antes de acionar o pipeline assíncrono. Observe que isso pode ocorrer no pipeline antes do estágio de acionamento. Não é necessário usar set_env duas vezes.
Marque a variável com export_env para exportá-la para a execução do pipeline assíncrono.
Qualquer variável marcada para exportação está disponível usando get_env no pipeline assíncrono.

set_env <variable-name> <variable-value>
export_env <variable-name>
get_env <variable-name>

Somente as variáveis marcadas estão disponíveis no pipeline assíncrono. Nem tudo pode ser exportado porque os dados podem ser muito grandes ou conter dados confidenciais.

Acionar o comando do pipeline assíncrono

Use o seguinte comando para acionar um estágio:

trigger-task <stage-name>

Código de exemplo

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"

Esse comando aciona a tarefa a partir do yaml de configuração do pipeline. Por exemplo, trigger-task owasp-zap.

O que está acessível no pipeline acionado

Todos os repositórios e artefatos que são salvos e exportados (usando set_env de pipelinectl e a ferramenta export_env ) no pipeline anterior também estão disponíveis no novo pipeline assíncrono acionado. Os repositórios são clonados com o commit no pipeline anterior nas mesmas pastas relativas ao espaço de trabalho. A confirmação dos repositórios deve ser salva em pipelinectl para que o pipeline possa clonar o mesmo estado do repositório.

Para acessar repositórios e artefatos, use list_repos e list_artifacts. Você pode obter todos os artefatos que foram criados e todos os repositórios que foram clonados, mas deve salvá-los em pipelinectl.

Não disponível Não está disponível nenhuma alteração no espaço de trabalho feita em tarefas anteriores na execução do pipeline acionado (por exemplo, npm install) porque não podemos passar todo o espaço de trabalho para a nova execução do pipeline acionado.

Como consultar o status do pipeline acionado

Chamada curl da 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

chamada de cli do ibmcloud

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

Para obter mais informações, consulte o comando IBM Cloud CLI(tekton-pipelinerun).

Para obter mais informações sobre o acionamento de pipelines usando a CLI, consulte Uso de acionadores