GitLabにパッチがマージされた話

κeenです。こちらの記事でGitLabからユーザのGPGキーを取得するURLがないとぼやいてました。

https://zenn.dev/blackenedgold/articles/b2b832c1b6e044dd0d9f

調べてもみつかりませんし、難しい機能でもなさそうなので実装してみることにしました。
実装したときのログはこちらのスクラップにあります。
https://zenn.dev/blackenedgold/scraps/c934ca8f2ba639a8aff4

目論見通り実装はできて無事マージされました。
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48321

この記事では下調べしてからマージされるまでの流れを振り返ってみようと思います。

既存のissueを検索する

まずはリリースされてないだけで既に実装されてないか、issueは上がったけど理由があって実装しないことになったりしてないかなどを調べます。ついでに、関連するissueを調べておくと後で役に立つこともあります。

私の場合は特に実装されてない理由などはなく、シンプルに思い付いた人がいないので実装されてないだけようでした。

ついでに関連issueもみつかりました。GPG KeyをAPIで公開するものと、SSH Keyを取得するURLを作るものです。

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43332/
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42288/

だいたいこの2つを組み合わせれば実装できそうですし、テストすべき箇所もわかります。それでは準備していきます

CONTRIBUTINGを確認する

マージリクエストを投げる前にルールを確認しておきましょう。プロジェクトによっては先にissueを立てて意見をもらってからマージリクエストを出すようなものもあります。あるいは、ブランチを切るときのベースブランチに指定があったりだとかの開発上の注意もあります。

GitLabはコントリビューションガイドをWebに置いてあります。

https://about.gitlab.com/community/contribute/development/

読んだところ簡単なissueをさがすといいよとはありますがissueからはじめないといけない、のような規則はありませんでした。安心して実装できそうです。
ブランチも最新のmasterからブランチを切ってmasterに投げればよさそうです。

pullしてmasterが動くことを確認する

GitLabをpullしてきてます。
巨大なプロジェクトで遅いのでのんびり待ちましょう。

普通はREADME、HACKING、CONTRIBUTINGあたりに動かし方を書いてあるのですが、GitLabにはありませんでした。代わりに上記コントリビューションガイドに「GDKを使え」とあります。
GDKとはこれです。GitLab Development Kitのことだそうです。

https://gitlab.com/gitlab-org/gitlab-development-kit

こちらはREADMEなどにインストール方法が書かれていました。

GDKのインストール

URLを1つ追加したいだけなんだけどな…と思いつつ乗りかかった船なのでツールを開発するためのツールをインスストールします。

先に asdf をインストールしてから
GDKのドキュメントに従って make bootstrap を打ちます。
aptインストールやらRubyのビルドやらなんやらが走り、必要な依存をインストールします。
準備できたら gdk init で初期化します。私の場合は先にgitlabをcloneしてしまっていたのでclone済みのリポジトリをgdkのディレクトリに移動させるなどの作業もありました。

一発では通らないので トラブルシューティングガイド 読みながら進めていきます。

GitLabの起動

gdk init が正常に完了したら以下のドキュメントを読みながらGitLabを起動します。

https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/doc/gdk_commands.md

gdk start で起動できます。

私の場合はここで実行中にサーバがエラーを吐く問題がありました。
ログとかを漁ると、私の環境（Ubuntu 20.10）でaptで入るGitのバージョンよりもGitLabの要求するバージョンの方が新しくてgitalyが動いていませんでした。
最新のGitをソースコードからビルドして ~/.local にインストールして対処しました。

GitLabへログイン

デフォルトで root/5iveL!fe でログインできるユーザが用意されています。
（以下のファイルで定義されています）

https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/fixtures/development/01_admin.rb

これでログインできれば色々試せるので準備完了です。

ブランチを切って開発する

先程発見した関連issueを切り貼りしたら特に難しいことはありませんでした。

実装したらローカルのURLにcURLを投げて期待通りの動作をしていることを確認します。

テストする

私がRailsに不案内なだけだと思いますが、テストが難しかったです。

まず、READMEにはテストの実行方法は見当りませんでした。なので勘で実行していきます。

rake test でテストできると期待したのですが、多くのテストが落ちてダメでした。

gdk start してると色々コンフリクトするのでサービスを落とします。しかしRedisやPostgreSQLは必要なので必要なサービスだけ起動しておきます。

最終的に bundle exec rspec /path/to/test_file.rb の方法に落ち着きました。これが正解だったのかは知りません。

必要なテストが全て通っていれば開発完了です。

マージリクエストを投げる

まずGitLabをforkして、自分のリポジトリの方にブランチを作ってpushします。forkが結構時間かかるので開発をはじめる前にやっておけばよかったです。
因みにレアケースを引いたのかは知りませんが私は一度forkに失敗しました。

一旦forkを削除してやり直したら成功しました。

あとは普通にマージリクエストを投げます。新機能を実装した場合のマージリクエストのテンプレートがあるので埋めていきます。チェックボックスがありますが、MRを出した人がチェックするのかレビュワーがチェックするのか分からなかったので空のままにしておきました。

マージリクエストの説明文にはこのMRをマージすると何が起きるのか、このMRで実装した機能はどう役に立つのか、参考例として類似サービスではこのような機能がある、などの説明を書きました。

反応を待つ

関連issueをレビューしてる人にメンションするか迷いましたが、GitLabは新着MRにひとまずレビュワーを自動アサインしてトリアージするフローを持っているようなのでそれに任せることにしました。

しばらくするとレビューがきて、スタイルの問題などを指摘してくれました。「全体的にはよさそうだよ、スタイルとかの指摘したから対応終わったらまた呼んでね」といって帰っていきました。

スタイルの変更をしてCIが終わるのを待ってたり自分がMR出したことを忘れて放っておいたりしてると別のコメントがついたりしましたが、私のMRをマージするののブロッカーにはならないだろうということで別のissueで対応されることになりました。

マージされる

レビューでの指摘事項を全部解消し、他のコメントも問題にはならないということでマージされました。マージのコメントでいつごろリリースされそうかとかも教えてくれました。
これにて作業完了です。

感想

GDKのセットアップが大変でした。
GDKのセットアップなどはドキュメントが分かりやすかったのですがGitLab本体は「Railsプロジェクトなんだから後は分かるよね？」でほとんどドキュメントがなかったのがつらかったです。Railsに詳しくないのが悪いと言われたらその通りですが。

まあ、でも簡易な機能ながら自分含め多くのユーザに使われているプロダクトに貢献できてよかったなと思います。