Fan-Out / Fan-In とは?

fan-outは作業を多数の並列jobに広げ、fan-inはそれらのすべての出力を単一のdownstream jobに集約します。

多くのpipelineには自然な形があります: 1つのjobが準備をし、多数のjobが並列で作業を行い、1つのjobが結果を集約します。fan-outが広げる部分で、fan-inが集める部分です。これはシャーディングされたテストとmatrix buildの基盤となっています。

パターン

• fan-out: buildまたはsetup jobがN個の並列job(シャード、matrixのセル)をトリガーします。
• 並列フェーズ: 各jobが自身のスライスを独立して処理します。
• fan-in: 最後のjobがそれらすべてを待ち、結果を統合します。

小さな例

build jobはmatrixを介して4つのテストシャードにfan-outします。report jobは needs に4つのシャードすべてを列挙するため、それらが完了した後にのみ実行され、その後に各シャードのartifactをダウンロードして1つのmergeされた結果を公開します。

fan-in jobが重要な理由

fan-in jobはすべての並列jobに依存するため、それらがすべて完了して初めて実行されます。ここでカバレッジをmergeしたり、統合されたreportを公開したり、セット全体の合格をdeployのgateにしたりします。

レポートのためのRun-on-failure

fan-inのレポートjobを、並列jobが失敗した場合でも実行するように設定しましょう(たとえば if: always())。そうしないと、何が壊れたのかを最も見たい実行でこそ、集約されたreportを失ってしまいます。

よくある落とし穴

fan-outの作業が不均等だと、fan-inが最も遅いブランチを待つことになり、並列化のメリットが失われます。また、fan-inの依存関係で並列jobを1つ忘れると、そのjobが完了する前にfan-inが実行され、部分的な結果を生み出してしまいます。

重要なポイント

• fan-outは作業を並列jobに広げ、fan-inはそれらの結果を集約します。
• fan-in jobはすべての並列jobに依存し、それらが完了した後に実行されます。
• レポートのfan-inを失敗時にも実行するようにして、統合されたreportを保持しましょう。

関連ガイド