OpenTacoのapply_requirementsを使ってApplyの条件を制御してみる
digger.ymlのapply_requirementsフィールドでdigger applyの条件を設定できます。
デフォルトはmergeableになっており、マージが可能な状態であればdigger applyを実行できます。
このフィールドには以下の値が設定可能です。
- approved: Pull Request(以降、PR)作成者以外の1人以上の承認(Approve)
- undiverged: PR作成後にmainブランチが変更されていない
- []: 条件判定をスキップ
それぞれ試してみます。
[mergeable]
以下のようにdigger.ymlを設定して、PRを作成しました。
projects:
- name: production
dir: prod
+ apply_requirements: [mergeable]
Pull Requestがマージ可能なことを確認して、digger applyを実行し成功しました。
マージ先のブランチに変更を加えて、コンフリクトを発生させました。
この状態でdigger applyを実行すると、想定通り失敗しました。
[approved]
digger.ymlを変更して、PRを作成しました。
projects:
- name: production
dir: prod
+ apply_requirements: [approved]
Approve前にdigger applyを実行すると失敗します。
Approve後にdigger applyが成功しました。
CODEOWNERS統合
apply_requirements: [approved]を利用する方法だと、承認者の制御はできません。(PR作成者以外のだれが承認者してもApplyが可能。)
特定のユーザーの承認を必須にしたい場合は、以下のCODEOWNERS統合を利用するのがおすすめです。
[undiverged]
digger.ymlを変更して、PRを作成しました。
projects:
- name: production
dir: prod
+ apply_requirements: [undiverged]
mainブランチにtest.mdファイルを追加して、PR作成後にmainブランチが変更されている状態にしました。
想定どおり以下のエラーが出て失敗します。
解消するためにローカル環境の作業ブランチで以下の操作を実行しました。
git switch <作業ブランチ>
git rebase origin/main
git push --force-with-lease origin HEAD
再度、digger applyを実行して成功することを確認しました。
[]
digger.ymlを変更して、PRを作成しました。
projects:
- name: production
dir: prod
+ apply_requirements: []
[]はチェックをスキップします。
コンフリクトさせた状態で以下のようにdigger applyを試してみました。
本来ならスキップして、成功するはずです。
しかし、試した際は以下のようにエラーがでてスキップができていませんでした。
ワークフローレベルのスキップの場合は、スキップしてdigger applyが成功しました。
projects:
- name: production
dir: prod
workflow: myprod
- apply_requirements: []
+workflows:
+ myprod:
+ workflow_configuration:
+ on_pull_request_pushed: ["digger plan"]
+ on_pull_request_closed: ["digger unlock"]
+ on_commit_to_default: ["digger unlock"]
+ skip_merge_check: true
おわりに
OpenTacoのapply_requirementsによる適用条件制御についてでした。
デフォルトはmergeableになっており、コンフリクト時にはdigger applyが失敗するようになっています。
意図しない上書きを防止する機能がデフォルトで入っているのは嬉しいですね。
