kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
community/contributors/guide/contributor-cheatsheet/README-ja.md

18 KiB
Raw Blame History

Kubernetesコントリビューターチートシート

Kubernetesにコントリビュートする際のtipsや、Kubernetesプロジェクト内で使用されているベストプラクティスなどの共通リソースのリストです。 これらのまとめや便利な情報へのクイックリファレンスはGitHubでのコントリビューションの体験をよりよいものにすることでしょう。

目次

便利なリソース

はじめに

SIGとその他のグループ

コミュニティ

ワークフロー

テスト

  • Prow - KubernetesのCI/CDシステム
  • Test Grid - 歴史的なテストや関連した情報を見る
  • Triageダッシュボード - よりよくトラブルシューティングをするために、似たような失敗をまとめる

重要なEメールエイリアス

  • community@kubernetes.io - コミュニティの問題について、コミュニティチーム(SIG Contributor Experience)の誰かにメールするアドレス
  • conduct@kubernetes.io - 行動規範委員会へ連絡を取るためのプライベートメーリングリスト
  • steering@kubernetes.io - 運営委員会へメールするアドレスで、公開アーカイブのある公開アドレス
  • steering-private@kubernetes.io - 運営委員会へセンシティブなことを伝えるためのプライベートアドレス
  • social@cncf.io - CNCFソーシャルチームへの連絡先(blogやtwitterアカウントなど)

その他の便利なリンク

  • 開発者統計 - CNCFが管理するプロジェクトの開発者統計情報

GitHub上での効率的なコミュニケーション

お互いに良くあるためにはどうしたらよいか

まず最初にCode of Conductをよく読んでください。

良いまたは悪いコミュニケーションの例

issueをあげる時や助けを求める時、礼儀正しくしてください:

🙂 「Yをやった時にXがコンパイルできませんでした。なにかいい方法はありませんか？」

😞 「Xが動かない！直して！」

PRを閉じるとき、どうしてmergeできないのか、誠心誠意説明し、伝えてください。

🙂 「この機能はXというユースケースをサポートしていないのでこのPRを閉じます。提案された形であれば、Yツールで実装される方がよりよいと思います。」

😞 「どうしてAPI規約に従っていないんですか？これは他でやるべきです！」

貢献する

CLAにサインする

コントリビューションを提出する前に、Contributor License Agreement(CLA)にサインする必要があります。Kubernetesプロジェクトは、あなたもしくはあなたの会社がCLAにサイン済みの場合にのみコントリビューションの受け入れを行います。

CLAのサインで何か問題があった場合、CLAトラブルシューティングガイドラインを参照してください。

Issueを開いたり返事をしたりする

GitHub Issueはバグレポートや改善要求、あるいはテスト失敗のようなその他の問題を追跡するための最初の手段です。ユーザーによるサポート要求の方法としては使用されていません。そのような場合はトラブルシューティングガイドをみて、Stack OverflowやKubernetesフォーラムに問題を報告してください。

参考:

Issueを作る

  • もし用意されているなら、Issue templateを使用してください。適切なテンプレートを使用することで、他のコントリビューターが返信しやすくなります。
    • Issue template自体に書かれている手順に従ってください。
  • 詳細な説明をIssueに記述してください。
  • 適切なラベルを設定してください。よくわからなければ、k8s-ci-robot(Kubernetes CI bot)というボットが、重要度を適切に判断するために必要なラベルを提案します。
  • /assign @<username>か/cc @<username>を使用して担当者をアサインする場合は選択的に行ってください。より多くの人にアサインをするより、適切なラベルを付ける方が効果的です。

Issueに返事をする

  • Issueに取り組む時は、他の人とバッティングしないように、コメントを残してください。
  • 自己解決した場合には、Issueを閉じる前に他の人にわかるようコメントしてください。
  • 他のPRやIssue(あるいはその他アクセス可能なもの)への参照を含めてください(例えば、 "ref: #1234" のように)。他の場所にある関連した作業を特定するのに便利です。

Pull Requestを開く

Pull request(PR)はコード、ドキュメント、あるいはgitリポジトリに格納されているその他のものに対してコントリビュートする際の主な手段です。

参考:

Pull Requestを作成する

  • 利用可能な場合、Pull Requestテンプレートの指示に従います。 それはあなたのPRに対応する人々の助けになります。
  • リンク切れやタイプミス、文法の間違いなどの簡単な修正の場合、他の可能性のある間違いについてドキュメント全体を見直してください。 同じドキュメントの小さな修正で複数のPRを作成しないでください。
  • PRに関連するIssueやPRで解決する可能性があるIssueを参照してください。
  • 一度のコミットで過大な変更を加えないでください。代わりに、PRを複数の小さなコミットに分割してください。 これによりPRのレビューが容易になります。
  • 何か説明を加える必要があると思われる場合は、PRにコメントしてください。
  • /assign @<username>でPRに割り当てるときは選択的にしてください。 過剰なレビュー担当者を割り当てたからといって、 迅速なレビューが得られるわけではありません。
  • あなたのPRが "進行中" とされる場合、名前の前に [WIP] を付けるか、/holdコマンドを使用してください。これは [WIP] またはHoldが解除されるまでPRがマージされるのを防ぎます。
  • あなたのPRがレビューされてない場合に、閉じて同じ変更のPRを新しく作成しないでください。@<github username> とコメントでレビュアーにPingしてください。

PRの説明文の例

Ref. #3064 #3097
All files owned by SIG testing were moved from `/devel` to the new folder `/devel/sig-testing`.

/sig contributor-experience
/cc @stakeholder1 @stakeholder2
/kind cleanup
/area developer-guide
/assign @approver1 @approver2 @approver3

PRの内容:

  • 1行目 - 他のIssueやPRへの参照(#3064 #3097)
  • 2行目 - PRで行われていることの簡単な説明
  • 4行目 - /sig contributor-experience コマンドでのSIGの割り当て
  • 5行目 - この特定のIssueやPRに関心があるレビュアーを/ccコマンドで指定
  • 6行目 - /kind cleanupコマンドでコードやプロセス、技術的負債の整理に関してIssueやPRを分類するラベルを追加
  • 7行目 - /area developer-guideコマンドで開発者ガイドに関してIssueやPRを分類
  • 8行目 - /assignコマンドでPRにApproverを割り当て。 Approverはk8s-ci-robotによって提案され、OWNERSファイルのオーナーのリストから選択されます。 Approverはレビューされた後のPRに/approveラベルを追加します

Pull Requestのトラブルシューティング

PRが作成された後、KubernetesのCIプラットフォームのProwによって一連のテスト が実行されます。テストのいずれかが失敗した場合、k8s-ci-robotは 失敗したテストへのリンクと有効なログをPRに返信します。

新しいコミットをPRにがプッシュすると、自動的にテストが再実行されます。

時折KubernetesのCIプラットフォームに問題がある場合があります。 あなたの貢献が全てのローカルテストに合格したとしても、 これらは様々な理由で発生する場合があります。/retest コマンドでテストを 再実行することができます。

特定のテストのトラブルシューティングの詳細についてはテストガイドを参照してください。

ラベル

KubernetesはIssueとPull Requestを分類し、優先順位を付けるためにラベルを使用します。 正しいラベルを付けることであなたのIssueやPRをより効果的に処理することができます。

参考:

よく使われるラベル:

ローカルでの作業

Pull Requestを作成する前に、ローカルである程度の作業を行う必要があります。 もしあなたがgitに慣れていない場合、Atlassian gitチュートリアルは良い出発点です。 他に、StanfordのGit magicチュートリアルは多言語に対応しています。

参考:

ブランチ戦略

KubernetesプロジェクトはGitHubの標準である "Fork and Pull" ワークフローを使います。 gitの用語で、あなたの個人的なフォークは "origin" と呼ばれ、実際のプロジェクトの gitリポジトリのことを "upstream" と呼ばれます。 あなたの個人的なブランチ(origin)をプロジェクト(upstream)の最新に保つために、 ローカルの作業コピー内で設定されてなければなりません。

Upstreamを追加する

upstream をリモートとして追加し、プッシュできないように設定してください。

# replace <upstream git repo> with the upstream repo url
# example:
#  https://github.com/kubernetes/kubernetes.git
#  git@github.com/kubernetes/kubernetes.git

git remote add upstream <upstream git repo>
git remote set-url --push upstream no_push

これは設定したリモートを一覧表示する git remote -v を実行して確認することができます。

フォークを最新に保つ

upstream から全ての変更を取得し、ローカルの master ブランチに "rebase" します。 これはローカルのリポジトリを upstream プロジェクトと同期させます。

git fetch upstream
git checkout master
git rebase upstream/master

あなたは機能への取り組みや修正をするためにブランチを作成する前に、最低限これをやるべきです。

git checkout -b myfeature

コミットをまとめる

スカッシュコミットの主な目的はきれいに読めるgitの履歴や加えられた変更のログを作成することです。通常これはPRの改定の最終段階に行われます。 コミットをスカッシュするべきかわからない場合は、作業を止めてPRのレビューと承認を担当する他のコントリビューターの判断に任せることをおすすめします。

git rebase を対話モードで実行して、保持するコミットとまとめるコミットを選択し、ブランチを強制的にプッシュします:

git rebase -i HEAD~3
...
git push --force

備考: レビュー担当者にPRへの tide/merge-method-squash ラベルの付与を依頼することも可能です。（このラベルはレビュー担当者が /label tide/merge-method-squash コマンドを実行すると付与されます。）tide/merge-method-squash ラベルを付与すると、botはこのPRを構成するすべてのコミットをまとめ、それにより LGTM ラベル（既に適用されている場合）の削除やCIテストの再実行が行われなくなります。