GitLabと仲良くなる

Pleromaの開発はGitLabが使われている。本稿では、GitLabの使い方情報と、Pleromaの開発に固有の事情を織り交ぜてやっていく。

developブランチとfeatureブランチ

まず超実践Gitは強いのでみんな読むといい。ところで、超実践Gitの既存の戦略を知るという節によると、Git界隈で使われているブランチの名前には、以下のような流派がある。

  • git-flow: development, features, hotfix, releases, master
  • github-flow: master

さて、PleromaのGitLabがどうなっているかというと、develop がデフォルトのブランチであり、feature/XXX というブランチと fix/XXX というブランチが大量に作られている。masterブランチは、存在するがまったく使われていない。

Pleromaの開発体制は、ブランチの名前はgit-flowだが、実際にやっていることはgithub-flowである。Pleromaのdevelopブランチは、github-flowにおけるmasterブランチと同じように使われている。そのため、インスタンスを運営したい人はdevelopブランチからコードを持っていくことになっている。

余談だが、ブランチの名前に / を含めることが普及しているのは、初心者にとっては割と驚きがある。

ブランチをいっぱい作る

開発者にとって最終的な目標の一つがマージリクエストを出すことだ。GitHubにおけるプルリクエストのことをGitLabではマージリクエストと呼ぶ。

マージリクエストの実体は2個のブランチの組である。これらのブランチは別のレポジトリに置かれていてもよい。いずれかのブランチに新しいコードがコミットされれば、マージリクエストの内容も変化していく。そのたびに、マージが成功したりコンフリクトしたりするし、テストが通ったり通らなかったりする。

マージリクエストを出すことを想定して、1個のブランチには1個のテーマのコードのみをコミットする。このようなブランチを特にトピックブランチと言うこともある。

トピックブランチとは別に、インスタンスで実際に稼動しているコードを入れるブランチも必要である。AGPLにより、インスタンスが独自機能を持つならば、コードを公開する義務があるからである。私はdistsnという名前のブランチにしたが、deploy/distsn のような説明的な名前のほうがわかりやすいかもしれない。

本稿の読者の知識をどのように想定すればよいかわからないが、クローンとは以下のようなコマンドをやっていくことである。-b のあとの feature/who-to-follow-panel はブランチの名前であり、最後の who-to-follow-panel はローカルのディレクトリ名である。

git clone https://git.pleroma.social/hakabahitoyo/pleroma-fe.git -b feature/who-to-follow-panel who-to-follow-panel

本家のdevelopブランチに追従する

インスタンスを運営しているならば、新機能を取り入れることは欠かせない。また、トピックブランチにおいては、他の開発者による変更と衝突がないようにするために、きりのいいところで本家のdevelopブランチに追従する必要がある。

この作業はGitLabではなくローカルのgitコマンドでやっていく。Pleromaのレポジトリにはpleromaとpleroma-feがあり、ここでは例としてpleroma-feの方でやっていく。

git remote add official https://git.pleroma.social/pleroma/pleroma-fe.git
git fetch official
git merge official/develop

git remote add はレポジトリをクローンしたときに1回やればよく、git fetch と git merge は本家のdevelopブランチに変化があったときにはやるべきである。余談だが、git remote add でスペルミスをやらかしたときの直し方は git remote set-url である。

応用としては、レポジトリをクローンしたときには、自分のレポジトリが origin という名前で登録されている。これに対して fetch と merge をやっていくことにより、トピックブランチから機能を取り込むことができる。

git fetch origin
git merge origin/feature/who-to-follow-panel

pleroma.distsn.org は本番環境が開発環境を兼ねているので、この方法でトピックブランチを取り込んで動作確認をやっている。

ESLintを倒す

PleromaのGitLabレポジトリでマージリクエストを出すと、自動的にテストが走る。マージリクエストではなく普通のコミットでも自動的にテストが実行される。pleroma-fe は JavaScript 的なもの (Vue.jsとwebpackあたり) で書かれているので、ESLintでチェックされる。Lintとは人類にコーディングスタイルを強制するプログラムで、ESLintはそれのJavaScriptのやつである。

ESLintを倒さないと気分が悪いので、倒す。JavaScript Standard Styleという偉そうな名前のやつが相手なので、あらかじめ読んでおくと倒しやすい。

ユニットテストを倒す

pleromaレポジトリはElixirで書かれているので、それ用のユニットテストフレームワークが作動する。ただし、テスト環境が壊れていることも多い。テストの結果を見て、自分が書いたコードとは関係なさそうなところがエラーになっていたら、マージリクエストのコメントあたりで発言すれば、強い人たちが直してくれそうである。

広告

Pleromaの開発環境を作る

Pleromaという異常な分散SNSがあり、3.distsn.orgというインスタンスを運営している。インスタンスの運営よりも独自機能をもりもりやっていくことに興味があるので、そのようにする。

インスタンスを設立する

Pleromaのインストールは公式のWikiを読めば難しくない。日本語もあるが、英語が苦痛でなければディストリビューション別のドキュメントを読むほうが早い。やっていきましょう。

余談ですが、マストドンと比較して、Pleromaのインストールの楽なところを挙げる。

  • メールサーバーの設定が不要。マストドンでは、メールサーバーを自分で建てるか、Mailgunあたりのメールサーバーを使う必要がある。
  • 管理者ユーザーの作成が不要。Pleromaには管理者ユーザーが存在せず、インスタンスの設定はローカルなファイルを編集することで行う。
  • 安価な計算機資源でまともに動く。さくらのVPS 512 MBでも余裕。

Pleromaのインストールの面倒なところは、Elixirのバージョンが最新である必要があり、ディストリビューションのパッケージではなく、Elixirのウェブサイトからパッケージを取ってくる必要があることである。前述の手順書にはこの方法も書いてあるので安心だ。

レポジトリが2個ある

開発環境を作るということは、ソースコードとやっていくということで、まずはPleromaのGitLabにアカウントを作る必要がある。GitHubに依存して生活していると、まずここが面倒だが、やっていく。

次に pleromapleroma-fe をフォークする。レポジトリが2個あるというのが割と驚きポイントである。pleromaはバックエンド (サーバーサイド)、pleroma-feはフロントエンド (クライアントサイド) であり、両者は別のレポジトリになっている。

独自機能をやっていくことに興味がなく、単にインスタンスを設立したいだけなら、pleromaレポジトリだけをクローンすればよい。なぜかというと、pleroma-feレポジトリをビルドした生成物を、定期的に (開発者が手動で) pleromaレポジトリにコピーしているからである。具体的には、pleroma-fe の /dist/index.html と /dist/static が、それぞれ pleroma の /priv/static/index.html と /priv/static/static にコピーされる。

ここで、pleromaレポジトリが ~/pleroma にクローンされており、pleroma-fe レポジトリが ~/pleroma-fe にクローンされているとする。まず準備として、pleroma-fe で以下をやっていく必要がある。(補足: pleroma-fe の開発環境を作る)

npm install
npm run build

すると ~/pleroma-fe/dist ディレクトリに生成物が入る。あとは以下のようなシンボリックリンクを作ればよい。

cd ~/pleroma/priv/static
mv index.html index.html_
mv static static_
ln -s ~/pleroma-fe/dist/index.html .
ln -s ~/pleroma-fe/dist/static .

これで動くと思う。pleroma-fe の側でコードを編集したときは npm run build で新しくなる。pleroma の側でコードを編集したときは、たいてい何もしなくても新しくなるが、ごく稀に MIX_ENV=prod mix ecto.migrate が要る。

やや面倒なのは、pleromaレポジトリの側でgit関連の操作をしたいときは、これらのシンボリックリンクを元に戻す必要があることだ。そのために、上記のコマンド例ではmvコマンドで元のファイルを残している。

config.jsonをやっていく

さて、pleromaレポジトリには /priv/static/static/config.json があり、pleroma-feレポジトリには /dist/static/config.json がある。これらは内容は同一であるべきであり、開発者がぼんやりしていない限りはそうなっている。とはいえ、このファイルはインスタンスごとに設定を書き換えて使うので、どちらか一方だけを書き換えるというミスがあり得る。すると、シンボリックリンクに切り替えたときに動作が変わることになる。両者を常に同一の内容に保つべきだろう。

訂正 よく考えたら pleroma-feレポジトリの /static/config.json が /dist/static/config.json にコピーされるので、/static/config.json を編集する必要がある。npm run build で更新される。

追記

ふむっふむっ