Gitea 用の dependabot パッチを書いている
GitHub - dany1468/dependabot-gitea
とりあえず動くけど、まだいろいろ微妙な部分が多い。
どんな感じか
以下はローカルの Gitea に対して実行したものだけど、とりあえず動いている様子がわかる。ラベルが付くかとかの細かい部分はこれから。
どんなパッチか
lib/ ├── dependabot/ └── hack/
lib の下にいきなり hack とかいう不穏なディレクトリがあるのでお察しかもしれないけど、Gitea 用の Client を追加した以外はほとんどオープンクラスで対応している。
dependabot は https://github.com/dependabot/dependabot-core でコードが公開されているので、ローカルからでも実行できる。ローカルから実行するには、以下のスクリプトが使える。
GitHub - dependabot/dependabot-script: A simple script that demonstrates how to use Dependabot Core
今回は、dependabot-core, dependabot-script の両方に手を加えるような形で対応している。
サービス追加がやりにくかった
dependabot-core は対応サービス (Github, Gitlab etc) の追加には開かれた実装にはなっていなくて、 case でサービスのスイッチをするコードがたくさんでてくる。
よって、今回はその部分をオープンクラスで上書きして Gitea 用の Client にスイッチできるようにするコードを書くことになった。
Gitea に API が不足していた
具体的には 「branch を作成する API」 と「複数のファイルの差分から一つの commit を作る API」 が現状存在しない。
よって、今回は PUT /repos/{owner}/{repo}/contents/{filepath} のファイルを更新する API でブランチを作りつつ commit を作るというやり方にした。もしかすると他にも代替となるいい方法があるのかもしれない。
この制限もあり、現在は一つのファイルしか更新ができないため、例えば Ruby だと Gemfile と Gemfile.lock の２つのファイルで更新が必要であるためうまく機能しない。
自分が今 .NET Core の開発現場にいるため、一先ずこういう状態になっている。（.NET Core は C# なら .csproj だけで依存を管理している）
いい方法が見つからなければ、一つのファイルの更新ごとに同じコミットメッセージの commit を作るという対応をすることになると思う。
API に頼らず、実行環境に checkout して、、、というのも考えたが、面倒くさい。。
upstream に入れたいか
一応 dependabot-core の folk にも修正は入れているのだけど、他の対応サービスに比べて Gitea がどれ程利用されているのか分からないのと、上述の API 不足による課題で、commits がいい感じにならないのが気になって躊躇している。
この辺は、実際今の現場で運用ができるようになって様子を見ようかなと思っている。
余談
.NET には上記の NuKeeper というライブラリ更新のツールもあり、うまく動作するのだけれど、実際には Pull Request を出して、さらにその更新を取り込んでいいのかの情報収集も必要で、となると dependabot のようなツールが欲しくなる。（いちいち CHANGELOG のファイルを探すのは面倒くさい）
数年前 Ruby の現場に居た時は tachikoma と以下の tachikoma_ai で似たようなことをしていた。
GitHub - sinsoku/tachikoma_ai: Give a comparing function on GitHub to tachikoma
余談 2
ここ半年ぐらいは、足回りの仕事中心で、コードといえば Jenkinsfile ぐらいしか書いていなかったが、久しぶりに Ruby を書けて楽しかった。今回のパッチを書くのに 2, 3 時間ぐらい使っているが、数日朝早起きした時間を使う程度で済んだのでちょうどよかった。（これで dependabot-core が他の言語で書かれていたら、そうはいかなかった。。。）
