非同期サブパイプラインを使用してステージをトリガーする
非同期サブパイプラインを使用することで、 .pipeline-config.yaml 設定ファイルに追加された任意のステージをトリガーすることができます。 それらのステージをパイプラインにインラインで追加する必要はないし、パイプラインを修正する必要もない。
以下のコード例を参照してください。
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"
ステージをトリガーするために、ウェブフック・トリガーがウェブフック・シークレットで作成される。 ウェブフックのシークレットは パイプラインのパラメータと Subpipeline Webhook Trigger のプロパティの subpipeline-webhook-token にあります。
subpipeline-webhook-token の値の更新についての詳細は、 async stage webhooks の更新を 参照してください。
新しくトリガーされるパイプライン名はステージ名（例： my-custom-task ）であるため、ステージ名が有効なパイプライン実行名であることを確認する。 ステージ名は、 Kubernetes リソースの名前またはIDを作成するために使用される。 Kubernetes、オブジェクト名とIDは RFC 1123 または RFC 1035に従わなければならない：
- 最大63文字。
- 小文字の英数字またはハイフン「-」のみを含む。
- 英数字で始める。
- 英数字で終わる。
非同期パイプラインにデータを渡す
ステージの実行に必要な変数を渡すことができます。 pipelinectl を使うことができる。
以下の手順で2つのパイプライン間でデータを渡すことができます：
set_envを使って、非同期パイプラインをトリガーする前に変数を保存する。 これは、トリガーステージの前のパイプラインで起こりうることに注意。set_envを2回使う必要はない。- 変数を
export_envでマークし、非同期パイプライン実行用にエクスポートします。 - エクスポート用にマークされた変数はすべて、非同期パイプラインで
get_env。
set_env <variable-name> <variable-value>
export_env <variable-name>
get_env <variable-name>
マークされた変数だけが、非同期パイプラインで使用できる。 データ量が多すぎたり、機密データが含まれている可能性があるため、すべてをエクスポートできるわけではない。
非同期パイプライン・コマンドのトリガー
ステージをトリガーするには、以下のコマンドを使用する：
trigger-task <stage-name>
サンプル・コード
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"
このコマンドは、パイプライン設定yamlからタスクをトリガーします。 例えば、trigger-task owasp-zap です。
トリガーされたパイプラインでアクセス可能なもの
の set_env と ツールを使用して）保存およびエクスポートされたすべてのリポジトリとアーティファクトは、新しいトリガー付き非同期パイプラインでも利用できます。 pipelinectl と export_env ツールを使って )保存されエクスポートされたすべてのリポジトリとアーティファクトは、新しいトリガー付き非同期パイプラインでも利用できます。 リポジトリは、前のパイプラインのコミットとともに、同じワークスペース関連フォルダにクローンされる。 パイプラインが同じ状態のリポジトリをクローンできるようにするには、リポジトリのコミットを pipelinectl に保存する必要があります。
リポジトリや成果物にアクセスするには list_repos そして list_artifacts. ビルドされたすべてのアーティファクトとクローンされたすべてのリポジトリを取得できます。
pipelinectl.
利用不可 すべてのワークスペースを新しいトリガーパイプライン実行に渡すことができないため、トリガーパイプライン実行の前のタスク（例えば、npm install）で行われたワークスペースの変更は利用できません。
トリガーされたパイプラインのステータスを照会する方法
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クリコール
ibmcloud dev tekton-pipelinerun [pipelineID] --run-id [pipelinerunID] [--output JSON]
ibmcloud dev tekton-pipelinerun ls [pipelineID]
詳細については、 IBM Cloud CLI(tekton-pipelinerun)コマンドを 参照してください。
CLIを使ったパイプラインのトリガーについては、 Using triggersを 参照してください