http://dev.chromium.org/developers/testing/commit-queue https://chromium.googlesource.com/chromium/src/+/master/docs/infra/cq.md
CQ
このドキュメントはChromiumコミットキュー(CQ)がどのように構成され管理されているかを記述する。これはChromiumのCQに特化したものなので、他のCQについてはinfra-dev@chromium.orgを参照。
目的
ChromiumCQは開発者のコード変更をchromium/srcへコミットする前にテストするためのもので、CLが影響するすべてのテスト一式を実行しパスすることを確認する。
オプション
- COMMIT=false
CLにこれを付加すると、コードは実験的であることを示し、CQ経由で間違って提出することを防ぐ。このオプションがあるとCQは即座に変更の処理を停止する。
- CQ_INCLUDE_TRYBOTS=<trybots>
このフラグで追加のボットを指定する。フォーマットは “bucket:trybot1,trybot2;bucket2:trybot3”。
- NOPRESUBMIT=true
提出前のチェックをスキップする。PRESUBMITにバグがある場合にのみ使うべき。
- NOTREECHECKS=true
ツリーのステータスチェックをスキップする。これによりCQはツリーが閉じられていてもCLをコミットする。ツリーは理由があって閉じられているので推奨されない。
- NOTRY=true
ツリーをグリーンに戻すために使う。トライボットをスキップするため、ツリーを壊すかもしれない。この目的以外で使うべきではない。
- TBR=<username>
See policy of when it's acceptable to use TBR (“To be reviewed”). If a change has a TBR line with a valid reviewer, the CQ will skip checks for LGTMs.
FAQ
CQは実際何を実行してるのか？
CQはcq.cfgに指定されているジョブを実行する。 cq_builders.mdを見て、リンク付きの自動生成されるファイルを参照。CQ上のビルダー情報がある。
いくつかのジョブは実験用。CQビルドの一定の割合で実行され、その結果はCLが着地するかどうかに影響しない。ファイルの先頭でリンクされているschemaをみればコンフィグのフィールドの情報がある。
CQは以下の構造を持つ：
- CLによって影響されるすべてのテスト一式をコンパイルする。
- CLによって影響するすべてのテストを実行する。
- 多くのテスト一式は破片(shards)に分割される。各破片は新規タスクとして分割して実行される。
- これらのステップは ‘(with patch)’ とラベルされる。
- Retry each shard that has a test failure. The retry has the exact same configuration as the original run. No recompile is necessary.
- リトライが成功したら、失敗は無視される。
- これらは ‘(retry shards with patch)’ とラベルされる。
- 同じコンフィグでリトライすることが重要。隔離してリトライするとしばしば失敗していたものの挙動が変わる。
- 失敗したテストをCLなしで再コンパイルし、隔離状態で再実行する。
- リトライが失敗したら、その失敗は無視される。ここではテストが壊れたと想定している。
- これらのステップは ‘(without patch)’ とラベルされる。
なぜ私のCQが失敗するのか？
以下の一般的なガイドラインに従う。
- パッチがビルド失敗を引き起こしてないかを確認する。
- コンパイルやテストが失敗していてもそれが自分のせいではないと思うときは、仲のいいシェリフにシェリフバグを提出する。コードがOWNERを持つならば、彼らにもCCする。
- 他の部分のCQボット実行が失敗した場合（bot_updateなど）、またはCQ自体が壊れていると思うとき、または何が問題かわからないときはトゥルーパーバグを提出する。
どちらのケースでもバグを提出するときは、ビルドへのリンクやCLを含めること。