プルリクエストの作成にGitpodを使ってみました！

はじめに

こんにちは、たかのと申します。
この記事は、クラウドワークス Advent Calendar 2020の12/3の記事になります。
個人的に使ってみて「おお！」と思ったGitpodについてのお話です。

こんな方にぜひどうぞ

特に、以下のような点にご興味ある方に読んでいただければ幸いです。

• OSSのプロダクトに対し、貢献をしてみたいという方
  • でももっと気軽に環境構築できたらいいなと思っている方
  • どうやって進めるのか実例をもう少し知りたい方
• お互いリモート、場所や機材が限られていても効果的に開発してみたい方

Gitpodってなに？

Gitpodは、クラウドとPC(デスクトップ) 双方で稼働が可能なIDE (統合開発環境)です。

「IDE? ただ単にクラウド上で動くエディタ？」と思われてしまうかもしれませんが、そうではなくて、本当に必要に応じて、ブラウザを通して利用できる「開発環境」が立ち上がります。

「このリポジトリ試したいな」「issueにのっとってコードを修正したいな」と思った時に、ちょっと待つだけで、ワークスペースが立ち上がります。ソースコードを修正し、かつ実行もできるように、ターミナルもシェルもミニブラウザも揃った形で、自分だけの環境として利用することができます。

"pod" という名前からイメージできるように、「個別の環境」をオンデマンドで用意する技術としてはDockerやKubernetesが利用されています。

GitHubから使ってみよう！

どこからはじめるの？

基本はGitpodのワークスペースは、GitHub/GitLab/Bitbucketのブランチ、issue、プルリクエストを元にして作成する形になります。
なにも存在しない形でのワークスペースは作れないので、かならず起点にするリポジトリが必要になります。

Chromeに拡張機能を入れている場合は、各ブランチを表示している場合はトップページの上部に、issueやプルリクエストは上部に「Gitpod」という緑のボタンが表示されます。
もしくは、URLを直接指定して、リポジトリに紐づいたワークスペースを作成となります。^[1]

---

※Gitpodのダッシュボード側には、ワークスペースを作成するUIはありません。

---

なにがおこるの？

リポジトリからの操作で、Gitpodへのワークスペース作成のリクエストが走り、Gitpod側の画面に遷移します。
ワークスペースという形で、コンテナが立ち上がるので、数十秒（30秒くらい？）待つと、ブラウザ上にVisualStudio Code風のオンラインエディタが立ち上がります。^[2]

起動すると、このような画面になります！

VS CodeではなくTheiaを使っています！

最初しばらくは、わたしもVisualStudio Code（以下: VS Code）かと思っていたのですが、こちらはTheiaというIDEでした。

Theiaは、Eclipseと同じく天文にちなんでいるのかな？
（テイアとかテアという書かれ方をしますが、動画の発音的には、"th" の音ですね）

どんな言語が使えるの？

特に指定が無い場合は、Gitpodのデフォルトのイメージをもとにワークスペースが作られます。

• Docker Configuration
• workspace-fullのDockerfile

Dockerfileを眺めてみると、本当に「全部入り！！」なのが分かりますね。
後述しますが、プルリクエストを出すためにワークスペースを立ち上げたら、即RubyやNode.jsが使えたので、とても驚いたのですが、こういう背景があるわけです。

プルリクエストのための作業をしよう！

では、本題のGitpodを使ってのコーディング（ここではプルリクのためのコード修正）のお話です。

今回は、お仕事で使っているOSSのgemに対してのプルリクエストです。
利用しているURLを新しいものに変更することが推奨されているので、置き換えを提案するという内容になります。

まずはフォークから

お作法はいろいろあると思いますが、まずは元のリポジトリをフォークします。

修正が必要な場合や外部にプルリクエストを出す場合、わたしは小心者なので、元のリポジトリにすぐにプルリクエストを出すことは滅多にありません。

フォークした自分のリポジトリのmaster / mainブランチに対してのプルリクエストを作成して、動作チェックをしていきます。^[3]

この予備のプルリクエストに対しては、作業中に見つかった疑問点や、想定外のことなどもどんどん書き出しておきます（もちろん日本語！）

こうしてある程度下書きをして、自分のリポジトリでCIを回してみて問題なさそう、という段階で元のリポジトリにプルリクエストを出します。^[4]

issueを作成しGitpodのワークスペースを作る

ブランチを伴うプルリクエストでも良いし、「プルリクエストを作るよ！」のような課題でもいいので、何かしらissueができれば^[5]、上記の通り画面右上に "Gitpod" のアイコンが表示されます。このボタンをクリックすると、ワークスペースが作成されます。

このとき、作業用のブランチが存在しておらず、課題のissueからワークスペースを作成する場合は、ワークスペース上に、タイトルから派生したブランチが作成されます。

Gitpod上で作業する

ワークスペースが出来上がると、あとはほぼPCでVS Codeを使ったような感じで作業を進めます。

コメントやREADMEの記載の変更程度なら、GitHub上で全て完結してしまってもいいのですが、今回はソースコード中の変数を書き換えになります。

すくなくとも、以下のようにテストを通す必要があるので、ワークスペースでGitやRubyが動かせないといけません。

• 提案したい箇所を直す（変数を置換）
• テストコードで変換前の値がハードコードされている箇所を直す
• 直した上でテストが正しく通るかを確認する
• 通ったらコミット
• 作業ブランチをpush

もちろん CONTRIBUTING.md も参考に...。

Rubyも入っている！！

さて、この手のイメージはNode.jsはよく入っているのですが、Rubyは微妙。
どうなってるかな？と思うと、rubyが入っている！！

gitpod /workspace/offsite_payments $ ruby -v
ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux]

とってもラッキーです！

次はテストの手順を確認します。README.md, CONTRIBUTING.md あたりに書いてあることが多いのですが、無い場合はどうするか。
CIと連携しているOSSのリポジトリなら、JenkinsやCircleCI, Travis CI向けの設定ファイルを探してみます。
今回の場合はTravis CIを使っているので、.travis.yml を眺めます。

すると、bundle exec rake test:units というテストスクリプトが書かれています。
これも、とてもシンプルでありがたい！！

すぐにテストが動いたよ！

ほぼ下準備なしに、bundle exec rake test:units を実行してみると....。

いやー、ちゃんと動きました。
大変に感動しました....。こんなに手間をかけずに動いてくれて何よりです！

ここで改めて記事を書いている段階で、このワークスペースのイメージが gitpod/workspace-full/dockerfile であることの意味を悟りました。

すぐ正式プルリク出せそう...とはいかなかった！

修正自体は簡単で、ワークスペースではテストが問題なし。
マージされるかどうかはオーナーの判断になるので、そこは祈るのみです。

その前に、次に予備プルリクエストを使ってCIでの動作確認をします。
まずは、個人でTravisとの連携を設定して、同じようにCIを回してみました。

Travis CIでは失敗しちゃった！

...しかし、失敗している！

Matrix Build (複数バージョンのRubyとRails使っているケースなどのGemfileの組み合わせ)のうち、1つが失敗してしまいました。

さすがにこの失敗している環境をすぐに作るには、Ruby2.5の環境を用意しないといけない...。

たまたまかと思ったのですが、元のリポジトリに対しての最近のプルリクエストでも、同様の箇所が失敗していました。ソースコードの修正以前に、ビルドの失敗原因を探す必要がありそうです。
そうしないと、プルリクエストを出しても、CIが通っていないからと却下されそうなので...。

メソッドが非推奨になったみたい

失敗のログを丁寧に見ていくと、使っているメソッドが非推奨になったらしく、そこを置き換えれば通りそうです。

• 関連Issue: https://github.com/rails/rails/pull/39152
  • Deprecate `starts_with?` and `ends_with?` for String core extensions

結果的に、本当に提出したいプルリクエストの前に、「非推奨になったメソッドを置換したプルリクエスト」を作成して、提出することにしました。

正式にプルリクエストを出したら？

怪しい英語ながらもプルリクエストを2つ作成し、Travis CIが周り出すのを待ちます。
....しかし、せっかく出したのに、待てども待てどもビルドが始まらず、ペンディングのまま！？

同じ形式の自分のリポジトリに対するプルリクエストでは、CIはちゃんと回っています。どうやらTravis CIの調子が悪かったのか、OSSでのクレジットに引っかかったのか。

「気長に待つかあ...」という感じで、とりあえずプルリクエストを出し切るという課題は達成としました。^[6]

ほかにもやってみたこと

上記の通りで、Gitpodを使ってブラウザのみでのプルリクエスト作成までが完了しました。他にも、いくつか試したことを添えておきます。

ワークスペースのイメージの変更

デフォルトのイメージではオーバースペックだったり、必要なバージョンのランタイムが無い場合があります。
そういう時は、.gitpod.yml や .gitpod.Dockerfile という形で設定を変えることができます。

リポジトリに含める必要はありますが、アプリケーションのワークスペースを作成すると同時に、アプリケーションを立ち上げる、といったことも可能になります。

Webアプリケーションのプレビュー

ワークスペース内でWebアプリケーションを立ち上げると、プレビュー用のブラウザがIDE内から利用できるようになります。

以下のような感じで、ワークスペース内からも確認できますが、一時的にポートを外部に公開して、外部からアクセスも可能にできるようです。

環境変数などは？

現在、Repl.it 上で動かしていた個人学習用のリポジトリも、そのままGitpodで動かせるようにしてみています。
あまり大したことは書いてはいませんが、設定ファイルなどを眺めていただければと思います。

• https://github.com/akiko-pusu/fcc-project-issue-tracker

上記のアプリケーションは、MongoDBを利用しています。
MongoDBはMongoDB Atlasのものを使っていますが、そのための接続情報は環境変数で渡しています。

Gitpodの場合は、Gitpod自体の個人の管理画面から環境変数を設定可能ですので、DBとの疎通さえ通れば問題なくアプリケーションの稼働ができました。

使ってみてのふりかえり

個人的には、「ブラウザだけで完結してしまう」というところが非常に気に入りました。
今まででも、Cloud9やrepl.it、GlitchといったオンラインのIDE＆実行環境がありましたが、リポジトリ側から即起動できるところも、良いなと思った点です。

あとは、慣れているVS Codeに近い感覚で利用できる点でした。

コードレビューができるらしい？

こちらの記事を拝見すると、Gitpodのワークスペースをブラウザを通してアクセスすることで、開発者どうしでワークスペースを共有しながらコードレビューができるようです。(やってみたい！)

• https://www.gitpod.io/blog/when-code-reviews-lgtm

一緒になって直にレビューをしていくことを、ここでは"Deep Code Reviews"という言葉で表現しています。なるほど。

VS CodeのLive Shareでも、同時に環境をシェアできますが、それぞれVS Codeだけは最低でも入れておかないといけません。（ほかにも方法があったら、わたしの認識不足ですので、あれば嬉しいです！）

Gitpodの場合は、ブラウザだけで完結するので、たとえばローカル開発環境にソースコードを残さなくてもいいという面でも、開発者の機動力が上がるのでは？という印象があります。
同時作業ができない場合でも、ワークスペースのスナップショットを取得して、そのスナップショットから、同じ環境を再現してもらうことができます。

注意点 / 制限

ワークスペース自体がコンテナとして動いていることと、今回は無償枠での利用のため、もちろんそれなりに制約はあります。

• 基本はリポジトリありきです
  • 個人ではなくチームやOSSとして公開されているリポジトリでもOK
• 無償枠は利用可能な時間に制限があります
  • ただし、一定時間アクセスや操作が無いと、30分程度でサスペンドしてくれます
• Docker in Dockerやdocker-compose.yml を使って他に必要なサービスをワークスペースの中で立ち上げることはできません^[7]

Theiaについての補足とか

Theiaの解説にあるように、

Eclipse Theia is an extensible platform to develop multi-language Cloud & Desktop IDEs with state-of-the-art web technologies. (Theiaのトップページから引用)

クラウドとデスクトップ双方で動かせるIDEということですが、実際どんなかんじなのか？
こちらについてもちょっと触れてみます。

デスクトップで使う場合は、一番お手軽なのは、Dockerイメージを使う方法があります。
デスクトップ環境のボリュームをコンテナにマウントさせて、ブラウザを通してコードを編集する形です。

そういう意味で、デスクトップ＆クラウド双方なのですね。

なるほど、バイナリパッケージを配布するんじゃなくて、もしDocker動かせる状態ならDockerイメージとして渡して起動してもらうのは、たしかにポータブル感がありますね。
また、アプリケーションとしてはNode.jsを使っているので、Dockerを使わずにローカルでビルドして立ち上げる方法や、Electronアプリケーションとしてパッケージ化したものを使う方法があります。

また、VS Codeのおなじみの拡張機能は、互換性を保つ形で公開されているOpen VSX Registry 上のものが利用できます。
（※自作で登録ずみのテーマが候補に出てこなかったので、「そういうことか！」と気が付きました...）

---

以上、わたしからの Gitpod と、それを使ってのプルリクエスト作成、ならびにTheiaについての記事でした。

リモートワーク、テレワーク中心の中で、開発環境にポータビリティがあったり、特別な用意がなくとも共有できるというのは、なかなか嬉しいものがあります。

また、日々の会社でのお仕事を通して、DockerやNode.js / TypeScriptといった技術に触れることで、このあたりがどういった仕組みで動いているのかを、おぼろげながら感じられるのも、面白いところです。

次はTheia向けに自作テーマを作成してみたいな、と思っています。
少しでも「OSS活動こうすればいいのか」「Gitpod使えば良さそうだな」と思っていただければ幸いです。

おまけ / 本日のZennメモ

この記事はZennを利用して記載しています。
zenn new:article で記事の雛型が作成できますが、--slug オプションをつけるとハッシュ値.mdではなくて指定のファイル名で作成できます。

zenn-contents $ npx zenn new:article --slug try-gitpod-for-pullrequest
📄try-gitpod-for-pullrequest.md created.

脚注

1. https://gitpod.io/# + リポジトリやブランチ、issueのURL といった形式です。詳しくはこちらをどうぞ！ (https://www.gitpod.io/docs/context-urls)

2. 1分程の動画も合わせてご覧ください。

3. 予備プルリクエストの一例はこちら。https://github.com/akiko-pusu/wordmove/pull/1

4. さすがに正式にプルリクエストを出すときは、心を砕きながら苦労しながら英語を書きます...。

5. 実は、プルリクエストも、issue(課題) も、どちらもGitHub上では大きくはissueの扱いになります。

6. 1日ほど経過したあとで、めでたくCIが周り、テストも全て通っていました。マージされるかコメントがもらえるかは、この記事を書いている時点では結果が出ていません。クリスマスプレゼントで、なにかしら反応があれば嬉しいです！

7. https://github.com/gitpod-io/gitpod/issues/52 のトピックをどうぞ！