Spring Bootへのプルリクがマージ・リリースされた!

プログラミング
この記事は約9分で読めます。

不慣れなのりお氏には、コードの修正以前にプルリク出すまでのお作法に苦労したので、その辺まとめておきます。

なお、Spring Boot へのプルリクがマージ・リリースされたのは事実ですが、へタレITブログというだけあって、ちゃんとへタレたオチがあります。。

はじめに

マージされたプルリクが含まれるリリースは v2.2.8.RELEASEv2.3.1.RELEASE です。

v2.2.8.RELEASE の方はContributorsに名前も載っていて単純に嬉しいですね。

準備:CONTRIBUTING.adocを読もう

まず最初にやるべきことは、そのままですが CONTRIBUTING.adoc を読むことです。

contribute するにあたっての説明や注意事項が書かれています。一度には頭に入りきらないと思うので、プルリクを出すまでに何度も参照することになると思います。英語が苦手な方は翻訳して控えておいてもいいかもですね。(もちろん常に最新の内容を把握するよう注意が必要ですが。。)

参考までにCONTRIBUTING.adocのコミット履歴です。

簡単に中身を見てみましょう。(意訳が下手だったらすみません。原文を読むか英語できる人に訳してもらってください。。)

Code of Conduct(行動規範)

まず最初に書かれているのはコントリビュータとしてのCode of Conduct(行動規範)です。

詳細はリンク先のCODE_OF_CONDUCT.adocに記載されています。

技術うんぬんの前に、人として、プロフェッショナルとして守るべきことが書いてあります。善良な方々は意識しなくても普段から守られているような内容だとは思います。セクハラするな、個人攻撃するな、プロフェッショナルらしくない行動はするなみたいな感じです。

従わない奴は永久に出禁にしてやる、と書いてあるので目を通しておきましょう。

Using GitHub Issues(Issueの使用に関するルール)

次に書かれているのは Spring Boot のGitHub Issueに関するルールです。ざっくりは下記2点が書かれています。違和感ない普通のルールだと思います。

  • GitHub Issues はバグやエンハンスの管理に使用してるから、一般的な質問はStack Overflowでやってくれ。「spring-boot」タグをつけとけば Spring Boot チームやコミュニティが見てるぜ。
  • バグ報告するなら、スピーディに解析できるようになるべくいっぱい情報提供してください。理想的には、問題を再現可能な小さいサンプルプロジェクトを含めてちょ。

Reporting Security Vulnerabilities(セキュリティ脆弱性の報告について)★超重要★

次の項ではセキュリティ脆弱性の報告について書かれていますが、これは超重要です。これを誤ると、Spring Boot チームに怒られるだけでなく、コミュニティや全Spring Bootユーザを敵に回すことになるでしょう。。

  • 脆弱性らしきものを発見しても頼むから我々が修正するまで公にしないでくれ。
  • 脆弱性はGitHub Issuesで報告するんじゃなくてhttps://pivotal.io/securityでどうにかしてくれ。

Sign the Contributor License Agreement(ライセンス契約にサインせよ)

次はコントリビュータのライセンス契約へのサインについて書かれています。ここはワクワクすることも書かれていますね。契約にサインするためのリンクも貼られているのでリンク先にしたがってください。(何やら動的なページだったので念のためここからはリンクは貼らないでおきます)

  • この契約によってメインリポジトリ(Forkされたやつじゃなくて本体)へのコミット権限を付与したりはしないよ。プルリクとかを受け入れるようにするってこと。
  • 活発なコントリビュータはコアチームに参加するように依頼されるかもね。そしたらプルリクをマージするチカラを手にするだろう。

サインは個人と法人で分かれているので、個人の方は「Sign Individual CLA」の方にサインしましょう。

なお、サインは必須です。サインしていない状態でプルリクを送ると、プルリク上にbuildmasterか何から、CLAにサインしてくださいみたいな自動応答があるのでサインできていなければそこで気付くと思います。(今探したらすぐに見つけられませんでしたが、以前たまたま見かけました)

Code Conventions and Housekeeping(コードの規約と保全)

ようやくこのあたりから技術的なお話になってきます。まずは、おなじみのコーディング規約や保全に関してです。

どれも必須ではないと書かれていますが(本当か?)、従っておくのが無難だと思います。数が多いので、雑めに紹介します。

  • コードのフォーマッタSpring JavaFormat を使用。(EclipseとIntelliJ向けに適用方法まで書いてあります。IntelliJに関しては Spring JavaFormat IntelliJ Plugin なるものまで用意されています。さすがSpring、、)
  • CheckstyleをかけたかったらGradleタスクを実行してね。(後述します)
  • 新規追加のJavaファイルには、最低限あなたを特定する@authorタグを含めたJavadocクラスコメントは書いてね。できれば何のためのクラスか説明も書いてね。
  • 新規追加のJavaファイルには、ASFライセンスヘッダのコメントを付与してね。(ヘッダは、プロジェクト内の既存ファイルからコピってちょ。←この辺はなんだかゆるいのね)
  • 変更したJavaファイルのJavadocクラスコメントには、あなたの@authorタグを追加してね。(表面的な変更じゃなくて、実質的な変更をしたファイルね)
  • まあ、Javadoc書いてね。
  • ちょっとUnitテストも書いてね。役立つやつを。誰かが書かなきゃいけないんだから。
  • ひとりで作業してるブランチだったら、現在のmaster(またはメインリポジトリのターゲットのブランチ)にリベースしてね。
  • コミットコメントを書く際はこの規約に従ってね。
  • Issueに対応した場合は、コミットコメントの末尾に「Fixes gh-XXXX」と書いてね。「XXXX」はIssueの番号だよ。

Checkstyleを実行するためのコマンド

$ ./gradlew checkstyleMain checkstyleTest

Mac向けのコマンドなので、Windowsの方はgradlew.batで上記のタスクを実行。以降でもgradlewコマンドを使用しているものは同様です。

Working with the Code(IDEについて)

IDEに好みがなければ、 Spring Tools SuiteEclipse を奨めるよ、とのことです。(そりゃあそうですよね)

STSやEclipseは昔使っていましたが、IntelliJを使ったら、Eclipse系には戻れなくなりました。。特にアルティメット版に手を出してからは。。STSのいいところをIntelliJに加えたみたいな感じになります。

IntelliJ(IDEA)のアルティメット版が気になる方は、下記紹介ページ経由で購入すれば500円引きになります。(微妙に宣伝すみません)

JetBrains製品を割引価格で! #侍割
ご紹介によりJetBrains製品の新規ライセンスに割引が適用されます

Building from Source(ソースからビルド)

Java8以上でGradleを使ってビルドできます。Spring Boot では Gradle Wrapper を提供しているので、プロジェクトのルートディレクトリで下記コマンドを実行します。

$ ./gradlew build

Importing into Eclipse(Eclipseにインポートする)

かなり丁寧かつ具体的に書かれているので省略します。 Eclipse Installer を使用する方法と、Buildship でマニュアルインストールする手順が記載されています。

Importing into IntelliJ IDEA(IntelliJ IDEAにインポートする)

Eclipse同様、詳細に説明されているため省略します。先述の Spring JavaFormat IntelliJ Plugin についても触れられています。

Importing into Other IDEs(その他のIDEにインポートする)

Gradleは多くのIDEでサポートされているから、IDEのドキュメント読んでね。

とだけ書かれています。そりゃそうですね。

Cloning the git repository on Windows(WindowsでのGitクローンについて)

どのフォルダにクローンするかにも依るけど、Widnowsのファイルパスの上限(260文字)を超えるファイルがあるかもしれないから、ファイル名長すぎエラーが出たら、Gitのcore.longPathsオプションを使ってね。

$ git clone -c core.longPaths=true https://github.com/spring-projects/spring-boot

いざ:Issuesを見てみよう

準備のCONTRIBUTING.adocだけでだいぶ長くなってしまいました。。Spring Boot のプルリクのお作法が分かったら、さっそくIssuesを見てみましょう。(ネタがある方は自分でissue切るなりすればいいと思いますが、、へタレには敷居が高い。。)

もうあんまり書くことないですが、まずは Good First Issuestatus: ideal-for-contribution (コントリビューションに理想的)、status: first-timers-only (初回のコントリビューション限定)などの取っ付きやすそうなラベルがついたIssueを見てみてはどうでしょう。

あとは、単純に type: bug ラベルのIssueとか?

さいごに(オチ)

なお、のりお氏のプルリクは実はコードではなく、ドキュメンテーションでした。(Good First Issueとかはドキュメンテーションが多かったです)

プルリクがマージされた通知メールが届いた時は嬉しかったのですが、その後の流れを見てみたら、、マージ後にコアチームの方(?)のコミットがあって、清書されていました。清書の中で、のりお氏の変更は全消しされ、いけいけな文章が追加されていましたとさ。

英語力が足りなかったのももちろんですが、清書の内容と見比べてみると、「注意事項」だけ書いて「じゃあどうすればいいか」を記述できていなかったのが大きな敗因な気がしました。

次回はコードのプルリクを出せればいいなーと思います。(1年半くらい前に、Spring WebFluxのエラーページ周りの小バグとその修正方法を発見したのですが、その時は先に他の方に修正されてしまったようで機会を逃しました、、)

コメント

タイトルとURLをコピーしました