ハンズオンで試してみよう!「Issue」と「PR」からはじめるKubernetesコントリビューション

はじめに

記念すべき第1回となった前回をお読みいただき、OSSやコントリビューションについて理解が深まった皆さま、次のステップとして実際に挑戦してみる気持ちは湧いてきましたか。もし「Kubernetes コミュニティに貢献してみたい!」と思ったらーー素晴らしい決断です! すでにとても大きな一歩を踏み出しました。これからKubernetesコミュニティの一員として、どのように貢献できるかを一緒に見ていきましょう。

様々なコントリビューションと進め方

「まずどんな貢献から始められるの?」と思うかもしれませんが、はじめに押さえていただきたいキーワードは「Issue」と「PR(Pull Request：プルリクエスト)」です。 IssueはGitHub上で課題や提案を共有するためのチケットで、バグ報告、改善点、または新しいアイデアなどが記録されています。

PRは開発者が行った変更をプロジェクトに取り込んでもらうためのリクエストで、「修正しました、レビューをお願いします!」という意味です。初心者におすすめなのは「good first issue」や「help wanted」というラベルが付いたIssueを探すことです。これらは比較的簡単で、はじめての貢献にぴったりです。ただし人気が高いので、すぐに他の人に取られてしまうこともあります。

次におすすめなのは「Kubernetesドキュメント」の更新です。一見地味に思えるかもしれませんが、ドキュメントはユーザーや初心者が参照するだけでなく、「CKAD」や「CKA」などの公式認定試験では実際にこのドキュメントを見ながら受験する形式になっているため、ドキュメントが常に最新の状態に翻訳・更新されていることが非常に重要です。興味のあるコンセプトに関するページを読んでみたり、誤字脱字や古い情報を見つけたら修正してみてください! これも、立派なコントリビューションです。

また、プロジェクト管理に興味がある方はリリースチームのShadowに応募するのもおすすめです。Kubernetesの各リリース前にはKubernetes公式Slackのsig-releaseチャンネルで新しいシャドウメンバーを募集しています。約3か月でKubernetesのリリースプロセスを学ぶことができます。ただし、かなり時間がかかる上、アジアのタイムゾーンからの参加は少し大変かもしれません。

もし、すでに具体的なアイデアや課題をお持ちであれば、思い切ってコントリビューターに相談してみましょう。Slackの各チャンネルで気軽に質問したり意見を共有したりできますし、各SIG(Special Interest Group)では定期的にミーティングが開催されており、議題を提案してディスカッションに参加することも可能です。ミーティングは録画も公開されているので、現在どのような課題が議論されているのかを後から確認することもできます。コミュニティのメンバーはとてもフレンドリーで、初心者の挑戦を歓迎していますので、安心してアクセスしてみてください!

オフラインイベントの機会があれば、参加すること自体もコントリビューションになるので、ぜひ積極的に活用することがおすすめです。私自身の経験からも言えることですが、Face to Faceで交流できる場では理解が深まるだけでなく、生身の人間の温かさや優しさを感じることで、より一層モチベーションが高まります。「KubeCon＋CloudNativeCon」はアメリカとヨーロッパで毎年1回ずつ開催されており、今年からは日本でも開催されるようになりました。併設イベントとしてコントリビューターやメンテナーが集まる「CNCF Maintainer Summit」も行われています。こうしたイベントに参加するチャンスがあれば、ぜひコントリビューターに声をかけてみましょう。挨拶やちょっとした雑談だけでも、貴重な交流のきっかけになります。

行動規範とCLA

やりたいことが決まったら、次のステップはコミュニティの行動規範を尊重しながらコントリビューターガイドラインを読み、「Contributor License Agreement(CLA：コントリビューターライセンス契約)」に署名することです。

Kubernetesコミュニティの行動規範は、簡単に言えば「良い人でいましょう」という、とてもシンプルなメッセージです。コントリビューターとして活動する際は、個人や所属企業の立場ではなく、コミュニティの一員としてのマインドを持つことが大切です。お互いを尊重し、協力し合う姿勢こそがコラボレーションの前提となりますので、貢献活動を始める前に、ぜひ一度ご確認いただければと思います。

CLAはOSSプロジェクトに貢献する際に必要な同意書で、貢献したコードやドキュメントの利用条件を明確にするものです。これにより、貢献内容をプロジェクトで自由に使用、改変、配布できる権利が確保され、知的財産権に関する問題に対処できるようになります。

初めてのPRを作成するとlinux-foundation-easycla botが自動でコメントを返してくれ、署名状況や手順のリンクが表示されます。「SIGNED AGREEMENT MISSING」と赤字で表示されている場合はまだ署名が完了していないことを意味し、クリックすると署名手続きのページに移動できます。CLAにサインアップする際は、Gitに設定したコミット用メールアドレスとCLA登録用メールアドレスが一致していることを確認してください。メールアドレスが異なると、PRの自動チェックで失敗することがあります。

署名手続きでは、GitHubアカウント情報へのアクセスを許可した後、貢献者の種類を選択します。個人として貢献する場合は「Individual Contributor」、企業の開発者として登録する場合は「Corporate Contributor」を選び、DocuSignを通じて署名を完了します。企業所属の場合は、企業内でCNCF開発参加者のリスト管理者(CLA Manager)に自分の名前の追加を依頼し、所属情報が変更になった場合はgitdmリポジトリで更新する必要があります。署名完了後に確認メールが届き、PR上で「/easycla」とコメントするとステータスが更新されます。

コード変更からPR作成まで(ハンズオン)

これで、ひととおり貢献者としての準備が整いました! 次のステップとして、自分の変更をPRに反映し、実際にコミュニティへ貢献する体験を始めてみましょう。

今回は「kubernetes-sigs/contributor-playground」という練習用のリポジトリを使って体験していただきます。このリポジトリは、新しいコントリビューターがKubernetesプロジェクトのレビューやPRの流れを安心して試せる「安全な練習環境」として用意されています。

Step 1: リポジトリをフォーク & クローン

GitHub上でcontributor-playgroundをフォークし、自分のアカウントにあるリポジトリをローカル環境にクローンします。

$ git clone https://github.com/<your-github-account>/contributor-playground

クローンできたら、新たに作られたcontributor-playgroundディレクトリに移動します。

$ cd contributor-playground

Step 2: upstream 設定

「upstream」とは元となる公式リポジトリのことを指します。まず、公式リポジトリから最新の変更を取り込めるように(この操作は「fetch」と呼ばれ、Step5で詳しく紹介します)、kubernetes-sigs側のリポジトリをupstreamとして追加します。

$ git remote add upstream https://github.com/kubernetes-sigs/contributor-playground

upstreamのリポジトリに誤ってpushしないように、no_pushを設定します。

$ git remote set-url --push upstream no_push

設定が正しく反映されているか確認したい場合は、git remote -vコマンドでチェックできます。下記のような結果が表示されれば、問題なく設定が完了しています。

$ git remote -v
origin https://github.com/<your-github-account>/contributor-playground (fetch)
origin https://github.com/<your-github-account>/contributor-playground (push)
upstream https://github.com/kubernetes-sigs/contributor-playground (fetch)
upstream no_push (push)

この結果を見ると、GitHubで公式リポジトリをフォークして、自分のアカウントにフォークしたリポジトリをローカルにクローンすると、自動的に「origin」という名前が割り当てられることが分かります。

つまり、originは自分のGitHubアカウントにあるフォーク先のリポジトリを指し、自分がローカルで変更する内容をpushする対象になります。それに対してupstreamは元の公式リポジトリを指し、公式リポジトリの最新状態を取り込む対象になる、という役割の違いがあります。この設定により、ローカルで作業しながらも公式リポジトリの最新変更を容易に取り込むことができ、PR作成時にコンフリクトを防ぐことができます。

Step 3: 作業ブランチを作成

masterやmainブランチはリポジトリの「原本」として扱われるため、変更を加えるときは直接masterやmainブランチで作業せず、必ず新しい作業用ブランチを作成し、そのブランチ上で変更・commit・pushを行いましょう。これにより他の人の作業に影響を与えず、安全に貢献できます。

新しい作業ブランチを作成します。

$ git checkout -b <your-branch-name>
Switched to a new branch '<your-branch-name>'

作業ブランチを作成したら、次のいずれかのコマンドで、現在どのブランチにいるかを確認できます。

$ git status
On branch <your-branch-name>
nothing to commit, working tree clean

または

$ git branch
* <your-branch-name>
  main

Step 4: ファイル作成 & commit

作業用ブランチに切り替えたら、次は作業フォルダに移動して変更を加えていきます。今回はコンフリクトを避けるために、remote/learners フォルダの下に自分のGitHubアカウント名をファイル名にした<your-github-account>.mdファイルを作成します。こうすることで、各自が独立したファイルを操作できるため、他の参加者の作業とぶつかることなく安全にPR作成を体験できます。

$ cd remote/learners/
$ vi <your-github-account>.md

ファイルを編集して保存したら、次のコマンドで正しく作成されているかを確認できます。

$ git status
On branch <your-branch-name>
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   <your-github-account>.md
no changes added to commit (use "git add" and/or "git commit -a")

次にgit addで作成したファイルを追加し、git commitでローカルリポジトリにコミットします。

$ git add <your-github-account>.md
$ git commit -m "Add <your-github-account>.md into remote/learners/"

“Add <your-github-account>.md into remote/learners/”はコミットメッセージで、修正内容を簡潔にまとめるものになります。リポジトリの履歴にも残りますので、あとで何を修正したのかが分かりやすく、誤解を招かないように簡潔かつ明確に書くことが大切です。

Step 5: upstreamの最新変更を取り込んでpush

cloneしてcommitするまでの間にupstreamリポジトリで更新があった場合は、それを自分の作業に取り込む必要があります。そのようなときは、upstreamをfetchしてrebaseすればOKです。

$ git fetch upstream
$ git rebase upstream/master

その後、ローカルリポジトリのブランチをリモートにpushします。

$ git push origin <your-branch-name>

これで端末の操作は終わりです🎉 ここまでできたら、あともう一歩です! ここまで進められたご自身に、拍手を送りましょう〜👏

Step 6: GitHub上でPRを作成

ローカルでの作業が完了したら、GitHub上でPR、つまり「自分が加えた変更を公式リポジトリに取り込んでください」というリクエストを作成しましょう。

ブラウザで「kubernetes-sigs/contributor-playground」にアクセスすると、画面上部に「Compare & pull request」ボタンが表示されているはずです。これは、先ほどpushしたブランチを使って新しいPRを作成できるというサインです。ボタンをクリックして次に進みます。

PRの作成画面ではタイトルと内容を入力します。デフォルトでは先ほどのコミットメッセージがタイトルとして自動的に入っていますが、必要に応じて修正しても構いません。タイトルの下には説明欄があり、ここで変更の概要や目的を記載します。ページ下部では、実際にどのファイルが修正されたのかを確認できます。

Kubernetesのリポジトリでは、PRテンプレートがあらかじめ用意されています。テンプレートにはPRの種類や修正内容、Issueとの関連などを記載するための欄が並んでいます。初めての方は、これをひと通り読んでおくと、どのような情報が求められているか理解しやすくなります。

まず“What type of PR is this?”の項目でPRの種類を指定します。今回はドキュメントを1つ追加しただけなので/kind documentationを残し、それ以外は削除します。「>」の記号が付いている行はコメントアウト扱いになるので、記号ごと消してしまいましょう。

次に“What this PR does / why we need it”の欄では「このPRが何を行っているのか」「なぜ必要なのか」を具体的に記載します。例えば、今回のように新しいファイルを追加した場合は、タイトルと同じく“Add <your-github-account>.md into remote/learners/”のように書けば良いと思います。

続いて“Which issue(s) this PR fixes”には、対応しているIssueがある場合にそのリンクを記載します。ここに記載したIssueはPRがマージされた際に自動でクローズされるため注意が必要です。今回はIssueに関連する修正ではないため、この部分は空のままで構いません。

最後の“Does this PR introduce a user-facing change?”の項目には、ユーザーの操作や挙動に影響する変更がある場合にその内容を記載します。特に影響がない場合は“NONE”と入力します。

すべて入力して「Create pull request」ボタンをクリックするとPRが作成されます。

初めてPRを作成した場合はCLAへの署名が必要になりますので、「行動規範とCLA」のセクションで説明したように「SIGNED AGREEMENT MISSING」と赤字で表示されている場合は、クリックしてCLAサインアップを完了させましょう。

PRが作成されると、自動的にreviewerにレビュー依頼が送られます。レビューアーが/lgtm(Looks Good To Me)ラベルを、アプローバーが/approveラベルを付け、すべてのテストを通過すればはボットによりPRが自動的にマージされます。

これで初めての貢献活動は完了です! おめでとうございます🎉、そして、ようこそKubernetes Communityへ! Kubernetesコミュニティの一員として、これから一緒に成長していきましょう!

PR作成時に知っておくと便利なこと

PRを作るときの注意点

PRを作成する際は適切なサイズに切り分けることが大切です。レビュアーにとって大量のコードやドキュメントを一度にレビューするのは大変で、マージまで時間がかかってしまいます。一方で誤字脱字やインデントの修正をファイルごとに大量のPRとして投稿すると、逆に鬱陶しいと感じられる可能性もあります。できるだけ意味のある単位でPRを作成しましょう。

プロジェクトごとに慣習はさまざまなので、自分の変更を提出する前に、ほかの人のPRをチェックして、やり方を参考にしてみても良いと思います。

Kubernetesリポジトリのラベル

場合によってはPR本文かコメント欄にラベルを追加することもあります。KubernetesではPRの対象モジュールを示すsigラベル(sig/testing、sig/node、sig/docsなど)や、PRの種類を示すkindラベル(kind/bug、kind/api-changeなど)がよく使われます。

sigラベルやkind ラベルはレビューすべき人に通知が届くため、PRを見つけてもらいやすくする大事な仕組みです。ハンズオンが終わったあとに他の人のPRを見て、どのようなラベルが付いているか観察してみるのも良い学びになります。

Kubernetesのラベルは非常に多く、どんなラベルがあるか知りたい場合は、ラベル一覧で見ることもできます。これらのラベルはKubernetesのリポジトリで使われているProwコマンドを使って付与されることも多いです。使用できるコマンドの一覧は「Command Help」にまとめられています。中には/meowのように猫の写真を表示したり、ジョークを返してくれたりする遊び心のあるコマンドも多数あります。興味のある方は、PRがレビューされるのを待っている間にコメント欄でラベルを試してみるのも大歓迎です。

レビューアを見つける

PRを作成するとボットが自動でレビュアーをアサインしてくれる便利な仕組みがありますが、場合によってはあまり活動していない人が指名されることもあるため、特定のレビュアーに見てもらいたい場合や、よりアクティブなレビュアーを指定したい場合には、自分で/assignコマンドを入力してアサインすることが可能です。SlackのSIGチャンネルでPRのリンクと一緒にレビュー依頼を行うのも効果的です。ただし、時差やレビュアーの都合もあるため、依頼後は2〜3日程度の余裕を持つことがポイントです。

また、ここで要注意なのが自動的にアサインされるのはreviewerだけで、approve権限を持っていない場合もあることです。その際は、自分で approverを探してアサインする必要があります。各リポジトリにはOWNERSファイルがあり、誰がapproverなのか記載されていますので確認してみましょう。

まとめ

今回はハンズオンを通じて、Kubernetesへのコントリビューションの流れを体験いただきました。きっと次の貢献に向けてワクワクしているのではないでしょうか! 本記事でも紹介したように、Kubernetesコミュニティでの貢献にはさまざまな方法があり、コードの修正やドキュメント更新だけでなくPRを見てコメントしたり、イベントに参加したり、ブログを読んで知識を深めたりすることも立派な参加の一歩です。今回の経験をきっかけに、ぜひ積極的にコミュニティに関わってみてください。皆さんと一緒にKubernetesコミュニティで成長できる日を楽しみにしています!

次回は「Kubernetes コミュニティ」と題してお送りする予定です。お楽しみに!