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

著者 Kaveh Alemi·Latchkey

「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の排除が、最もレバレッジの高い節約だ。

よくある質問

What is What are CI minutes and how does billing Work??

Most CI providers meter usage in minutes of job time. Understanding rounding, multipliers, and what counts as billable time is the difference between a predictable bill and a surprising one.

What counts as a minute?

Billing typically tracks each job’s execution time - from when it starts running to when it finishes - and rounds up to the nearest whole minute. A job that runs 61 seconds is usually billed as two minutes. Queue time is generally not billed, but cold-start setup inside the job is.

Machine multipliers?

Larger runners and non-Linux operating systems apply a multiplier. A minute on a big Windows or macOS runner can count as several Linux minutes, so the same work on a heavier machine costs disproportionately more.

Why bills surprise teams?

Per-job rounding punishes pipelines with many short jobs (a 200-job matrix of 30-second jobs bills 200 minutes, not 100). Re-runs from flaky or transient failures double the cost of the same work. And oversized runners chosen "just in case" multiply every minute.