MariaDB にコントリビュートした話 - VSCode on EC2で開発環境の構築

数少ない読者へ愛を込めて

「MariaDB にコントリビュートした話」ってタイトルでブログ書いてください✋
— N. Yanagisawa (@NayutaYanagisaw) May 19, 2022

MariaDBに初めてコントリビュートした時の作業記録をまとめる。Issue自体は一番簡単なものを渡してもらったので、最も初歩的なことはじめの参考程度にご覧ください。

開発環境の用意

初めに開発環境を整える。MariaDBのビルドは重いとよく話に聞いていたので、手元のMacでは心もとない。仕事柄使いやすいEC2を採用。オレゴンに c5.2xlarge を建てた。

↓を参考にすればよいが、今回はAmazon Linux 2上で動かしたいので、UbuntuではなくCentOS向けの手順を使う。

nayuta-yanagisawa.hatenablog.com

sshログインしたら、これを打てばOK。

sudo yum-builddep mariadb-server
sudo yum install git \
      gcc \
      gcc-c++ \
      bison \
      libxml2-devel \
      libevent-devel \
      rpm-build

VSCodeで開発する

CLIでは開発できない人間なので、VSCodeをつなぐ。この手順を参考にする。

blog.serverworks.co.jp

これにより、エディタのみVSCodeでファイルの実体の管理やビルドの処理はEC2に任せることができる。

ちなみによりセキュアにしたければ、SSMを経由してEC2に接続すると良い。これにより、EC2のセキュリティグループでポート22のIngressを許可しなくてもssh接続できるようになる。具体的な方法は以下のブログに詳しい。

blog.logical.co.jp

ビルドする

git clone --branch 10.3 https://github.com/MariaDB/server.git mariadb-server
mkdir mariadb-server/bld && cd $_
cmake -DCMAKE_BUILD_TYPE=Debug ..
cmake --build . --config Debug -- -j 4

作業ディレクトリに大量のファイルが出力されるので注意しよう。上のコマンドのように、最初に一時ディレクトリへ cd することをおすすめする。

また、うちの環境だと -j 4 の前に -- を付けないと動かなかった。-j の後の数字は並列数みたいなので、c5.2xlargeに合わせて8にした。これでコアを使い切れる。

何をやっているかよく分かってないが、エラーが出てないので問題ないのだろう。ちなみに重いと覚悟してたが、初回ビルドだと数分程度だった。今回はさほどイテレーションもなかったので、それほどつらくない。

Issueを直す

今回取り組むIssueはこちら。柳澤さんが認める一番いい good first issue である。

jira.mariadb.org

前職以来使ってないJIRAの見方を忘れたが、おそらく親も子もない単体Issueと思われるので、これだけを手がかりに着手する。

まず、タイトルにある SPIDER_HAS_MY_CHARLEN でgrepすると、2箇所しかでてこない。確かにこれは good first issueのようだ！

コードを見ると、常に #define SPIDER_HAS_MY_CHARLEN されるようになったので、 #ifdef SPIDER_HAS_MY_CHARLEN の条件分岐を消して良いことがわかる。もちろん、絶対に通ることのない #else の方を消す。

消して、ビルドが通ることを確認する。

cmakeを3に上げる

と思ったらエラー！

実は作業ブランチを途中で切り替えたのだった。リポジトリを見ると最新ブランチが10.9ぽいため。10.3のときはビルドが通っていたが、10.9では以下のエラーでビルドが失敗するようになっていた。

CMake Error at CMakeLists.txt:107 (CMAKE_MINIMUM_REQUIRED):
  CMake 3.0.0 or higher is required.  You are running version 2.8.12.2

以下を参考に、cmakeのv3をインストールする。

www.matbra.com

インストール後再度ビルドすると、無事にビルドが完了した。

ちなみに実際は作業を開始すべきブランチがIssueにより異なる模様。今回も結局 10.10 が正解だった。ここはMaintainerに聞くか、IssueのFix Version/s を見るのが良さそう？

Pull requestを出す

テストの実行の仕方がわからないが、GitHubにPRを立てれば自動で実行されるようだ。それを使おう。

GitHubでフォークして、cloneしたリポジトリのURLを書き換える。

git remote set-url origin git@github.com:tmokmss/MariaDB-server.git

念の為 CONTRIBUTING.md を確認したが、特に変わったルールはない模様。他のPRも参考にしながら、PRを書いた。

CIやレビューはどれくらいかかるかわからないので、今日はここまで。

追記) なんとものの1時間でレビューが完了し、マージされた！もちろん最小規模のPRであるのも理由だろうが、それでもこの速さはなかなかない。一開発者としては気持ちの良い経験だった。

感想

まだ深淵の縁にも立ってないと思うので、何もわからない。git bisect の話をよく耳にするが、それを使う程のバグfix系Issueだと少し深淵を覗けるのかもしれない。とはいえ、今回のIssueくらいなら、手軽に初められる印象だった！

また時間があれば手を出したいと思う。

maybe daily dev notes

私の開発日誌