CI分とは何か、課金はどう機能するのか?

「CI分」はjob実行の実時間の1分だ。落とし穴は切り上げとマシンごとの乗数で、これが請求を生の実行時間より速く増やす。

ほとんどのCIプロバイダは、job時間の分数で利用を測る。切り上げ、乗数、そして何が課金対象時間になるかを理解することが、予測可能な請求と驚きの請求の違いだ。

何が1分になるか

課金は通常、各jobの実行時間 - 実行開始から終了まで - を追跡し、最も近い整数分に切り上げる。61秒動いたjobは通常2分として課金される。queue時間は一般に課金されないが、job内のcold startのセットアップは課金される。

マシン乗数

より大きなrunnerと非LinuxのOSは乗数を適用する。大きなWindowsやmacOSのrunnerでの1分は、複数のLinux分としてカウントされうるため、より重いマシンでの同じ作業は不釣り合いに高くつく。

• Linuxは通常1xのベースライン。
• WindowsとmacOSはより高い乗数を持つ。
• より大きなCPU/RAMのtierは、OS係数の上に乗算する。

請求がチームを驚かせる理由

jobごとの切り上げは、多数の短いjobを持つpipelineを罰する(30秒のjobが200個のmatrixは、100分ではなく200分を課金する)。flakyまたは一時的な失敗からの再実行は、同じ作業のコストを倍にする。そして「念のため」に選ばれた過大なrunnerは、あらゆる分を乗算する。

メーターを減らす

• 依存関係をcacheして、各jobがセットアップに費やす課金対象秒を減らす。
• runnerを適正サイズ化する; 必要のない乗数を払わない。
• flakyな再実行を減らす - すべてのretryに課金される。
• 切り上げで丸1分を失う小さなjobを統合する。

重要なポイント

• CI分はjobの実行時間を測り、ほぼ必ず切り上げられる。
• マシンのOSとサイズが、生の分に乗数を適用する。
• 多数の短いjobとflakyな再実行が、最も請求を膨らませる。
• cache、適正サイズ化、flakeの排除が、最もレバレッジの高い節約だ。

関連ガイド