TL;DR
自動でPRを作るGithubActionsを実装してたら使ってるプラグインのバグを見つけたよ。
せっかくのOSSコントリビュートチャンスだから修正したよ。
やってみたら以外と簡単にできたし達成感もあったからみんなも機会があったらOSSコントリビュートをやってみよう！
そしてこれも便利だからみんなも使ってみてね！
これはなんのお話？
業務中に触っていたプラグインのバグを見つけたので初めてのOSSコントリビュートをしたお話。
コントリビュートチャンス、到来！
そもそも何をしてたの？
もともとは運用改善のために、特定のブランチにPRがmergeされたら自動で上位環境へのリリースPRを作成するGithub Actionsを作りたかった。
つまりdevelopにmergeしたらdevelop->stagingのPRを、stagingにmergeしたらstaging->productionのPRを自動で立てるようにしたかったのだ。
たくさんの人が触るRepositoryになってくると、自分以外の人の変更がなんなのかを追うのすら大変になってくるよね。
例えばdevelop環境に既に入っている変更が既に動作確認済みであるかどうかということを知るために、現状だとそれぞれの作業者にSlackで確認をするしかない。
これをなんとかするために
- 自動でPRを立ててくれる
- チェックボックスで作業者が確認済みかを記録できる
の2つができるような方法を探していた。
（正確には自動でPRを立てる仕組みは既にチームで作っているものがあったのだが、簡易的なものだったのでチェックボックスの情報の引き継ぎなどができていなかったよ。）
この仕様を満たしてくれるプラグインが都合よく転がっていたらいいのになぁ〜！
あった。
あったのだ。
git-pr-releaseを使えばどうも両方を満たしてくれるらしいことが分かったのだ。
これを見つけたときは喜びのあまり、日頃は滅多に行かない高めのスーパーでちょっといい果物を買ったよ。
これでいろんな人が好き勝手にmergeをしても誰がどんなPRを出しているのかが一目瞭然になるぞ。
試しに実装してみた
なんとも都合よく新規のプロジェクトがあったので、試しに上記のプラグインを使うGithub Actionsを実際に作ってみたよ。
name: Create Release Pull Request
on:
push:
branches: develop
permissions:
contents: read
pull-requests: write
jobs:
create-staging-release:
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/develop'
steps:
- name: Checkout Branch
uses: actions/checkout@v4
- name: Setup Ruby
uses: ruby/setup-ruby@v1
with:
ruby-version: 3.3
bundler-cache: true
- name: Install specific_install
run: gem install specific_install
- name: Install git-pr-release
run: gem specific_install https://github.com/x-motemen/git-pr-release.git
- name: Run git-pr-release
run: git-pr-release
env:
GIT_PR_RELEASE_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GIT_PR_RELEASE_BRANCH_PRODUCTION: staging
GIT_PR_RELEASE_BRANCH_STAGING: develop
GIT_PR_RELEASE_LABELS: StagingRelease
GIT_PR_RELEASE_TEMPLATE: .github/workflows/git-pr-release.erb
TZ: Asia/Tokyo
そしてこれを実行すると、いい感じにPRも作られているし、チェックボックスも付いている！
いくつかのチェックボックスにチェックを付けてrerunをして再生成しても消えずにちゃんと残っている！
これでサクッと改善でWinだ！
チェックボックスの様子がおかしい
喜んだのも束の間、チェックボックスの様子がおかしいパターンがあることに気づいた。
// 変更前
- [x] #1 super awesome commit 1 @secobaka
- [ ] #2 super awesome commit 2 @secobaka
// 変更後
- [ ] #1 super awesome commit 1 @secobaka
- [ ] #2 super awesome commit 1 @secobaka
- [ ] #10 super awesome commit 10 @secobaka
- [ ] #11 super awesome commit 11 @secobaka
// 期待している形
- [x] #1 super awesome commit 1 @secobaka
- [ ] #2 super awesome commit 1 @secobaka
- [ ] #10 super awesome commit 10 @secobaka
- [ ] #11 super awesome commit 11 @secobaka
// 実際の形
- [x] #1 super awesome commit 1 @secobaka
- [ ] #2 super awesome commit 1 @secobaka
- [x] #10 super awesome commit 10 @secobaka
- [x] #11 super awesome commit 11 @secobaka
おかしい。
10や11にはチェックを付けていないはずだ。
何回か動かして挙動を確認しコードも確認したところ、どうも「PR番号を前方一致で確認しているため、#1のPRのチェックボックスの状態が#10,#11などにも波及している」ということが分かった。
新規プロジェクトの最初の方にありがちなBigBangRelease(めちゃめちゃ変更を含んだデカいリリース)のときなどに頻発しそうな事象だね。
無念、ここまでか…と思っていたところ、チームメンバーの1人が「せっかくOSSの不具合を見つけたのだからコントリビュートすればいいのでは？」という提案をしてくれた。
ここを逃したらたぶん一生やらないだろうなという確信があったので、コントリビュートチャレンジをしてみることにしたよ。
Let's コントリビュートチャレンジ！
正直なんも分からん
チャレンジするぜと言ったはいいが、正直に言うとOSSコントリビュートのOの字も知らない。
でも、先人の記事なんかを参考にさせてもらいながらよちよち歩きでOSSにコミットしていったけどなんとかなったぞ。
以下がその手順だよ。
Repositoryによってはコントリビュートの際のルールがCONTRIBUTING.mdにまとめてある場合があるよ。
まずはそれがないかを確認しよう！
例: https://github.com/neovim/neovim/blob/master/CONTRIBUTING.md
forkする
まずは元になるRepositoryをforkするぞ。
そうすると自分のRepositoryの一覧にforkしたRepositoryが追加されるよ。
とりあえずそれをローカルにcloneしよう。
作業用ブランチを切る
ローカルにcloneして、baseブランチから作業用のブランチを切るよ。
このときのブランチ名はなんか命名規則がないかとか一応確認してもいいかもしれないね。
ちなみにPRを見てたらユーザ名:ブランチ名(secobaka:fix/allow-big-bang-release-pr)みたいになってるけどここの名前のとこは勝手に付くからブランチ名につけなくてもいいよ。
修正する
問題の原因になっているコードを修正するぞ。
自分のイケてるコードがOSSという歴史に爪痕を残す姿を想像しながら力強くキーボードを叩くのがポイントだよ。
ちなみにテストがちゃんと書いてある場合は、必ずテストが通るかを確認した方がいいと思うよ。
今回だと
- 事前にあるべきのテストを書く
- 正規表現の判定部分を直したら良さそうだったからそこを直す
- もう一回テストを流して通ることを確認する
のステップを踏んで修正確認したよ。
PRを出す
修正をpushしたらGithib上でPR作成をするよ。
そうすると恐らくfork元のRepository宛のPRが作成できると思うのでそれを選択するよ。
このときのPRの内容ももし決まっているフォーマットがあるならそれに則って書いていこう。
英語で書かないといけないときは、丁寧に日本語の文章を書いた後にChatGPTに食わせたらAlakazamって寸法よ。
ちなみに今回作ったPRはこちら。
https://github.com/x-motemen/git-pr-release/pull/100
震えて眠れ
無事PRを出した後は「クソ舐めたPRを投げてこないでください。」って言われてcloseされるんじゃないか…って怯えながら震えて眠ろう。
ちなみにここでよりよい改善方法について提案が入ることがあるよ。
僕の場合は「正規表現こっちの方が無難だよ」っていう提案が入ってたから取り込んだよ。
こうやって新しい知識を得られるのもいい体験になるね。
念願のmerge
ownerによさげだな〜と判断されたらPRがmergeされるよ。
その日はぜひ君の新たな挑戦の成功を祝って、仲間と喜びを分かち合い、日々酷使しているPCやキーボードたちにお辞儀をし、家族に日頃の感謝を伝え、ランチもディナーもいつもより少しいいものを食べよう。
君はそれだけのことをやったんだ！
喜びを分かち合う仲間がいないって人は僕に連絡をくれ。
一緒にドミノピザの一番大きいやつを食べよう。
最後に
OSSコントリビュート、やってみるまでは難しそうなイメージだったけど、実際にやってみるとやること自体はシンプルだったよ。
今回はバグを修正するコミットだったから修正方針が固まればスっといけたし、何より「修正方針が間違っていても、バグってることは間違いない」っていう確信があるから安心だったよ。
みんなもOSSコントリビュートをして、インターネットの海にいい爪痕を残そう！
参考にした資料
- GitHub Actions リリースプルリクエストを自動生成する
- これで君もOSSコントリビューター！