Skip to content
Latchkey

workflowファイルとは何か?パイプラインを定義するドキュメント

workflowファイルとは、パイプラインを定義する通常YAMLのドキュメントで、いつ実行するか、どんなjobがあるか、各jobがどんなstepsを実行するかを定めます。

workflowファイルは、pipeline-as-codeが具体化する場所です。CIシステムに何をすべきか伝えるために実際に書くファイルです。構造はプラットフォーム間で一貫しています。triggersのセクション、jobsのセット、そして各job内のstepsです。workflowファイルを読めるようになることは、パイプラインを読めるようになることです。

workflowファイルの構造

  • triggers: workflowを開始するイベント。
  • jobs: 独立した作業単位、多くの場合並列。
  • steps: 各job内の順序づけられたコマンドまたはaction。
  • config: runnerの選択、変数、permissions。

どう発見されるか

プラットフォームは、既知の場所をスキャンしてworkflowファイルを探します。GitHub Actionsは .github/workflows/ 以下のすべての .yml を読みます。各ファイルは独自のtriggersを持つ別々のworkflowなので、1つのリポジトリが多数持てます。

簡単な例

ファイルは on:(trigger)で始まり、次に jobs:、各jobの下に runs-on:steps: のリストがあります。このわずかな数のキーが、数十行の読みやすい行でパイプライン全体を記述します。

1つのリポジトリ、多数のworkflowファイル

関心事をファイルにまたがって分割すると、各々が読みやすく保たれます。テスト用のCIファイル、公開用のreleaseファイル、スケジュールされた実行用のnightlyファイルです。各々が独立してトリガーするので、互いに干渉しません。

workflowファイル vs パイプラインの実行

workflowファイルは静的な定義であり、実行はその1回の実行です。ファイルを編集すると将来の実行が変わります。ファイルはレシピ、実行は料理です。

重要なポイント

  • workflowファイルは、パイプラインを定義するYAMLドキュメントです。
  • triggers、jobs、stepsを持ち、既知の場所から発見されます。
  • 1つのリポジトリが多数のworkflowファイルを保持でき、各々が独立してトリガーします。

関連ガイド