🐧

automerge できなかった Renovate の Pull Request を Issue として管理

2022/05/26に公開

OSS

Renovate

tech

e.g. renovate-issue-action によって自動で作成・Close された Issue

automerge できなかった Renovate の Pull Request を Issue として管理するために作った OSS を紹介します。

背景・課題

以前 Terraform Monorepo に対する Renovate の大量の Pull Request を処理するための技術に関する Blog を書きました。

この中で CI が失敗したら直ぐに PR を close してブランチも削除する という tips を紹介しています。詳細はブログを読んでください。
ブログにも書いてあるとおり、 Close した Pull Request は後で対応する必要がありますが、大規模な Monorepo で多くの人・チームが関係し日々多くの Pull Request が作られるような環境では、この対応が後手に回ってしまい、適切に処理されないこともあるかと思います。

対策

適切に対応していくには、まず対応するというタスクを Issue として管理するのが良いでしょう。
態々 Issue を作らなくても Close された Pull Request をチケットとして扱うというやり方もありますが、 Issue にすることで以下のようなメリットがあります。

Open か Close かでタスクの状態を管理できる
残っているタスクの数や処理されたタスクの数を把握しやすい
複数の Close された Pull Request を一つの Issue にまとめることができる

3 について補足すると、 Renovate は新しいバージョンが出れば新たに Pull Request を作成するので、問題が未解決なままだと新たな Pull Request も Close されます。
つまり Pull Request をチケットとして扱う場合、チケットが重複して作成される場合があります。
関連する Renovate の Pull Request を同じ Issue に関連付けることでチケットの重複を防ぐことが出来ます。

次のスクショは Issue の description に複数の Close された Pull Request のリンクがリストアップされている状態です。 Pull Request は 2 つ close されていますが、 Issue は一つに集約されています。

Issue の自動作成

Renovate の Pull Request が merge されずに close されたら自動で Issue を作成するツールを作りました。

このツールを GitHub Actions で Pull Request が close されたら実行するようにします。
Issue の title は Renovate の packageName や packageFileDir によって一意に決まるようになっています。 renovate-issue-action は title で Issue を検索し、 Issue がなければ新規作成し、既にあれば Pull Request の URL を Issue の description に追記します。

Pull Request がマージされた場合、該当する Issue が存在すればそれを Close します。

ただし、 Renovate 以外が作成した Pull Request では Close されません。
つまり、人間が Pull Request を作成して修正したとしても自動では Close されません。
それを自動化するのは難しいし、人間が Close すれば済む話だからです。
Renovate の Pull Request を基本 automerge する場合、対応する Issue の Close も自動化する必要があります。

Issue に関する属性 (リポジトリ, title, body, assignees, labels, projects, etc) を設定ファイルで変更できるようになっています。
これらの属性は Renovate の packageName や packageFileDir によって変更することが出来ます。
update されるファイルの owner に応じて label や project を変えるというのが一つの使い方かなと思います。

e.g. projects/service-a 配下のファイルが update されたら @aquaproj/service-a にメンションし、 owner:service-a label をつけて Project service-a に追加する

  - if: Metadata.PackageFileDir startsWith "projects/service-a"
    issue:
      additional_body: "@aquaproj/service-a"
      additional_labels: ["owner:service-a"]
      projects:
        - service-a

team に assign できれば便利ではありますが、 GitHub Issue の仕様上 team を Issue に assign することは出来ません。そこで team ごとに label をつけたり body で team にメンションしたり、 team の project に追加したりするようにします。

さいごに

以上、 automerge できなかった Renovate の Pull Request を Issue として管理するために作った OSS を紹介しました。

このブログでは細かい部分は説明していないので、詳細はドキュメントを読んでください。

このツールは便利ではありますが、このツールを使ったからといって automerge できなかった問題が勝手に解消されるわけではなく、相変わらず人間の対応が必要です。
Issue が作られても放置されていては意味がありません。
Renovate による update は直ぐ対応しなくても多くの場合直ぐには問題にはなりませんし、
プロダクトの機能に直結するわけでもないですし、多くの方は他にも様々なタスクを抱えています。そのため放置されることもあるでしょう。

Renovate の Issue に適切に向き合うには恐らく以下のようなことが必要でしょう。

Issue の存在・ Issue を作成している背景をチーム・組織に知ってもらう
- なにも知らない人にいきなり Issue を assign したりしても相手は困惑するかもしれません
Issue に対する運用ルールをチーム・組織で定める。 Issue 対応が評価に繋がるようにする(ボランティアに依存しない
オーナーにタスクが適切に割り振られ、オーナーが Issue の存在に気づき、管理できるようにする
- renovate-issue-action の設定のチューニング

ということで、さいごに色々書きましたが、もし同じような課題を持ってる方々の参考になれば幸いです。

背景・課題

対策

Issue の自動作成

さいごに

Discussion