Prowの真骨頂であるTideでPRの自動マージを導入する。
前回のエントリ「ProwではじめるChatOps on GitHub。」からProwを完全理解した!と言ってはいけない。Prowの真骨頂はTideにあると思う。
Enable kustomize in kubectl by Liujingfang1 · Pull Request #70875 · kubernetes/kubernetes · GitHub
上記のProwが有効になったPRのフローの最後を見てほしい。BotアカウントがPRをマージしているのだ。この仕組みはProwのTideが実現してくれる。
Tideは一定の条件を満たした上でPRをマージしてくれる。マージを行うアカウントはProwに設定したGitHubのアクセストークンになるのでBotアカウントになる。一定の条件は下記のようなyamlでセットアップを行う。
|
|
上記のqueriesに含まれるreposやlabelsの条件を満たせばTideがPRをマージしてくれる。
このエントリでは
このエントリでは、Tideのセットアップの方法とPRフローに必要そうなProwプラグインのセットアップ方法をまとめていく。
Triggerプラグインを有効にする
Triggerプラグインは /ok-to-test
, /test xxxx
, /retest
などのキーワード入力からProwJobsを実行するプラグインである。(Prow Plugin Catalogのtriggerを参照)
Triggerプラグインのセットアップ手順をまとめていく。次のようなconfig.yamlを用意する。
|
|
上記のコンフィグレーションにより /test unit-test
というキーワードが有効になった。Prowはキーワードとレポジトリ(soushin/bazel-multiprojects)がマッチすればPodを起動してalpineイメージから /bin/printenv
のコマンドを実行する。e2eテストが実行できるコンテナイメージを用意すればGitHubのコメントからe2eテストが実行できるようになる。ここらへんはプロジェクトに応じてしっかりとした準備と検討が必要なところだ。
always_runやskip_reportはプロジェクトに応じてセットアップする。詳細はjobs.mdにまとまっているので参照してほしい。
上記のconfig.yamlを用意したらConfigMapに反映する。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
(test-infra) $ cat config.yaml presubmits: soushin/bazel-multiprojects: - name: unit-tests always_run: false skip_report: false spec: containers: - image: alpine command: ["/bin/printenv"] (test-infra) $ kubectl create configmap config \ --from-file=config.yaml=config.yaml --dry-run -o yaml \ | kubectl replace configmap config -f - |
またplugin.yamlにはTriggerプラグインを有効にした上でConfigMapに反映する。
1 2 3 4 5 6 7 8 |
(test-infra) $ cat plugins.yaml plugins: soushin/bazel-multiprojects: - size - trigger (test-infra) $ kubectl create configmap plugins \ --from-file=plugins.yaml=plugins.yaml --dry-run -o yaml \ | kubectl replace configmap plugins -f - |
これでProwのhookポッドにTriggerプラグインとTrigger対象のProwJobs(unit-tests)が有効になった。
Triggerを実行する
任意のPRを作成して /test unit-tests
を入力した後にCheckにProwJobsが加わっている。
もしProwJobs(unit-tests)がエラーになればBotアカウントがお知らせしてくれる。
エラーになればコードを修正して /retest
を入力して全てのテストを実行する。Prowは登録されているProwJobsを実行して結果をGitHubに返す。
Triggerの流れを整理
Triggerプラグインを有効にしたProwは次のような流れになる。
- ReviewerはPRコードを確認してOKなら
/ok-to-test
を入力する。 - Prowは
ok-to-test
のラベルを付与する。 - Comitter(またはReviewer)は
/test xxxx
を入力してProwJobsを実行する。 - Prowはレポジトリに有効になったProwJobsを実行して結果を報告する。
- エラーの場合は
/retest
を促す。 - ReviewerはChecksを確認して必要なProwJobsがすべてSuccessedになっているか確認する。
上記のChatOpsのフローを交えてPRマージまで進める。
LGTM, Holdプラグインを有効にする
Tideを有効にする前にLGTM, Holdプラグインを確認していきたい。(Prow Plugin Catalogのlgtm, holdを参照)
このプラグインは/lgtm
,/hold
のキーワードを入力するとそれぞれlgtm
,do-not-merge/hold
のラベルを付与してくれるプラグインである。これを有効にしてTideの設定値であるlabelと組み合わせる。
次のようにlgtm
とhold
を有効にしてConfigMapに反映する。
1 2 3 4 5 6 7 8 9 10 |
(test-infra) $ cat plugins.yaml plugins: soushin/bazel-multiprojects: - size - trigger - lgtm - hold (test-infra) $ kubectl create configmap plugins \ --from-file=plugins.yaml=plugins.yaml --dry-run -o yaml \ | kubectl replace configmap plugins -f - |
/hold
、/hold cancel
でdo-not-merge/hold
ラベルの付与と取外しを行い/lgtm
でlgtm
ラベルを付与している。
※ 1人でエントリをまとめていたので/lgtm
と/hold cancel
をBotアカウントが行ってしまっているが本来はコントリビューターが行うことになる。
Tideを有効にする
PRマージを行うまでに必要なテスト(Trigger)とラベル付与(LGTM, Hold)を有効にするプラグインをまとめきた。これでTideを有効にしたPRフローの準備ができた。
Tideはconfig.yamlに次のようなコンフィグレーションを追加して有効にした。
|
|
PRマージの対象のレポジトリと必要なラベルと必要ないラベルの設定が有効になっている。
これまでと同様にconfig.yamlをConfigMapに反映する。
1 2 3 |
(test-infra) $ kubectl create configmap config \ --from-file=config.yaml=config.yaml --dry-run -o yaml \ | kubectl replace configmap config -f - |
Tideが有効になったPRフローを確認する
Tideが有効になったPRにはChecksにtide
が追加されている。
lgtm
のラベルが必要なのでラベルを付与するとProwが自動でPRをマージしくれる。
まとめ
- ProwのTideを有効にする方法をまとめた。
- またTideをPRフローに合わせるために必要なProwプラグインをまとめた。
- TideがあればマージまでのPRフローが明確になる。オープンなレポジトリを運営する際のコントリビュートのルールやプロジェクトチームのPRルールにProwを導入すればコミッターは迷わずPRフローを進めることができる。
- Prowプラグインには
assign
やwip
などPRフローに必要なものがあるのでチームにフィットしたプラグイン選びをしていきたい。