🦫

初めてのOSSコントリビュート to actions/setup-go

2023/06/12に公開

Git

こんにちは。新卒2年目エンジニアのyukyanです。

今回は、初めてOSSにコントリビュートした体験を、備忘録として残したいと思います。コントリビュート方法に関しては他の記事でたくさん解説されていますので、そちらにお任せして、この記事ではきっかけや流れ、個人的な学びについてお話します。

コントリビュートしたOSS

今回コントリビュートしたのは、actions/setup-go というOSSです。

https://github.com/actions/setup-go

GitHub Actions で、バージョンを指定してGoの環境を作成する際に使われる action です。

コントリビュートまでの流れ

このOSSの落とし穴

この action ですが、README.md にあるように、下記のように設定ファイルの go-version にバージョンを指定することができます。

uses: actions/setup-go@v4
with:
  token: ${{ secrets.GH_DOTCOM_TOKEN }}
  go-version: '1.18'

上記の場合はバージョン 1.18 と解釈されます。では、次の場合はどうでしょうか。

uses: actions/setup-go@v4
with:
  token: ${{ secrets.GH_DOTCOM_TOKEN }}
  go-version: 1.20

一見バージョン 1.20 を指定しているように見えます。しかし、これで実際にセットアップされるのはバージョン 1.2 です。数字で指定しているためか、内部処理で末尾の0が削ぎ通されてしまうのです。そのため、バージョン 1.20 を指定するためには以下のように、クォーテーションでバージョンをちゃんと囲む必要があります。

uses: actions/setup-go@v4
with:
  token: ${{ secrets.GH_DOTCOM_TOKEN }}
  go-version: '1.20'

最初 README.md を参照しながら開発を行っていたのですが、当時はシングルクォーテーションでバージョンを囲んでいないymlが例示されていました。それを見て実装していた私は、なぜかプログラムが正しく動かない現象に大いに悩まされました。

きっかけ

この問題は https://blog.stenyan.jp/entry/2023/02/03/085844 で指摘されているように認知はされていたようですが、元のリポジトリには反映されていませんでした。そこで、「これはOSSコントリビュートチャンスなのでは！？」と気づいたのです。

元々先輩エンジニアの yukun さんの記事を見て、OSSコントリビュートがどんなものなのかというのは把握していたので、すぐ取り掛かることができました。実際に作成したプルリクエストがこちらです。

内容は README.md の修正と、 action.yml 内のdescriptionへの追記です。

文面は全てDeepLに任せています。

座して待つ

4月7日にプルリクエストを作成し、Review Required にしたのですが、およそ２ヶ月、反応が全くありませんでした。レビュワーは自動で指定されたので、通知は届いていたはずですし、スターが1kを超えているリポジトリなので多くの人の目に止まってはいると思うのですが、誰からのレビューもなく、たまに見に行ってはレビューが何もないことを確認する日々が続きました。
そんな中、一人だけ 👍 をPRにつけてくれた方がいて、心の支えになりました。

マージ

PRを出してからおよそ２ヶ月後、 dmitry-shibanov さんが approve をしてくれたという通知を受け取り、mainブランチに自分のPRが取り込まれることになりました。長く待ったのもあり、正直めっちゃ嬉しかったです。

学び

今回のOSSコントリビュートには、いくつかの学びがありました。

意外とOSSにコントリビュートできるチャンスはある。
- 問題の範囲が小さいと、問題を認知している人が少ないのでコントリビュートしやすい
- 問題の影響範囲が複数リポジトリに渡ると、認知はされていても対応が漏れているリポジトリがあるケースがある
- OSSへのコントリビュートへの心理的ハードルの高さ（既存issueの調査、コードリーディング、コントリビュートガイドの順守など）
PRを作成してから反映までには長く時間がかかることがある
- これはリポジトリごとにまちまちで、すぐ返信が来るリポジトリもあれば、このリポジトリのように長い間取り込まれないこともあります。
被りはあまり気にせず、とりあえず立ててみるとイイ！
- あまりに乱立させると迷惑かもしれませんが、数分調査してみて、被る issue がなさそうだと判断すればとりあえず立ててみると良いかもしれません。実は今回、 actions/setup-go の他にも cli/cli にissue を立てていました。あわよくば実装ができればと思ったのですが、issueを立てた後に、同じようなissueがあると教えていただきました。コントリビュートできなかったのは残念ですが、新しい知識を教えていただいたので、いい経験になりました。 https://github.com/cli/cli/issues/7290
Contributors に載れると嬉しい。
今回の変更はたった２行なのですが、それでもコントリビューターであることには変わりなく、リポジトリの Contributors に載ることができます。このリポジトリはGitHubのエンジニアの方が多くコミットしているので、そうした強強な方々と顔を並べられるのは光栄に思います。

最後に

一回慣れてしまえばなんてことない、普段の開発と変わらない作業なので、ドシドシやっていきたいと思いました！
正直モチベはなんでもいいと思います。

他のエンジニアに同じ轍を踏ませたくない
便利なオプションをリポジトリの利用者に提供したい
就活・転職を有利に進めたい
バグを一つ残らず駆逐したい
コントリビューター王になりたい
リポジトリを進化させるため、mainブランチと自分のPRの同化をしたい

どんなモチベであれ、数十人〜数千人が利用するリポジトリへのコミットは、間違いなく学びがあるので、マージされなくてもまあいっか！の精神でトライしてみるのをお勧めします！