Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

Mavenプロジェクト用Travis CI設定(2017年末)

今年はビルド周りで自分の常識がいろいろ変わった年だったので、既存の知見もあわせてまとめます。

Mavenのバージョンを固定する

Travis CIは不定期にビルド用仮想マシンを更新しますが、そのタイミングでの最新のMaven仮想マシンに入れるようです。このブログ投稿時だと3.5.2が入っています。

もっと新しいバージョンを使う、あるいはMavenのバージョンを固定するには、Maven Wrapperを使うと良いでしょう。Travis CIはプロジェクトルートディレクトリにmvnwスクリプトがある場合はそれを優先的に使います。

mvnコマンド指定時の注意点

scriptinstalldeploy などのフェーズで mvn コマンドを明示的に実行する場合、 -B オプションを忘れないようにします。このオプションによってMavenインタラクティブなログを抑制するようになり、ログサイズが激減します。Travis CIはログサイズに上限があるため、うっかり忘れるとビルドが不安定になります。

グローバルにコマンドラインパラメータを指定する方法

グローバルにコマンドラインパラメータを指定する場合、それがローカルでの実行時にも必要となるパラメータならば、Maven 3.3から導入された .mvn/maven.config あるいは .mvn/jvm.config を使うことも可能です。ただし現状これらのファイルはコメントを書けないので、チームで使用する場合はどこかで説明が必要でしょう。

SonarCloudによるコード解析

FOSSならSonarCloudを使えば無料で解析できます。Travis CIには専用Addonがあって、MavenでSonarQube専用プロパティをややこしく設定しなくても、pom.xmlをよしなに解析してプロジェクトホームやIssueトラッカのURLを見つけてくれます。

なおコード解析をPRにも働かせる場合は、PRのもととなるブランチも同じリポジトリに存在する必要があります。これはトークンの復号化に必要なためです。

Travis CIによるSonatype Nexusへのデプロイ

これを取り入れるかどうかは意見が別れるところだと思います。というのもこれをやるには、暗号化済みとは言えGPG署名に必要なファイルやSonatype Nexusのパスワードをリポジトリにコミットする必要があるのです。

私の場合、個人プロダクトでは使わずに Maven Release Pluginを使うようにしています。ただしSpotBugsのような共同リポジトリの場合、リリース難度を下げ属人性をなくすために使用しています。

作業内容は単純に、GPG public keyring, GPG secret keyring そしてGPG passphaseとSonatype Nexusアカウント情報を含んだ settings.xmlを暗号化してリポジトリにコミットし、それをデプロイ時に使うだけです。以下のPRが参考になると思います。

GPGのkeyringは以下のようにコマンドで出力できます。

$ gpg --export $KEY_ID > .travis/pubring.gpg      
$ gpg --export-secret-key $KEY_ID > .travis/secring.gpg      

またリリースの属人性をなくすため、リリース手順書も合わせてコミットしておくと良いでしょう。settings.xmlのテンプレートもあると、引継や暗号化済みファイルの更新に役立ちます。

Contributorに対するリマインド

GitHubPRやIssueにテンプレートを作成することができます。またContributing Guidelineを作成することもできます。従来はこれがユーザに対するほぼ唯一のIssue/PR作成時のリマインダでした。

ただチェックボックスをテンプレートに入れたとしても、すべてのContributorがこれを使ってくれるわけではありません。ので、個人的には以下のブログで紹介されているProbotに期待しています。

SpotBugs 3.1.0 RC6の利用とフィードバックのお願い

先日SpotBugsの最新版となる3.1.0 RC6が出ました。大きな問題が無ければ、これが最後のRC版となる予定です。

SpotBugs開発において、私は新マニュアルサイト整備CHANGELOG整備、Ant廃止、Gradleスクリプト整備、Travis CI整備、Bot管理、パフォーマンス改善、JUnit用test-harness作成、Gradleプラグインの統合テスト作成、などなど色々やらせてもらいました。昨年FindBugsがforkされてからの10ヶ月間で数多くの変更と修正を入れてきましたが、どうにかJava9リリースのタイミングに合わせる形でSpotBugsの安定版をリリースできそうです。
助けていただいた各位、特にドキュメントの日本語訳にコントリビュートしてくださっているKannoさんと、SpotBugsチームの要請に応えてv6.1を出してくださったApache BCELメンテナ各位に御礼申し上げます。

このバージョンにはMANIFEST.MFに記載されたClass-Pathが間違っているという既知の問題がありますが、MavenやGradle、AntなどのビルドツールあるいはEclipseによってFindBugs/SpotBugsを使っている場合には問題になりません。ぜひ日頃の趣味開発ないし業務開発で使っていただいて、イシュートラッカーにフィードバックをお願いします。
なおjarコマンドあるいはSpotBugsが提供するスクリプトを利用されている方は、こちらに記載のMANIFEST.MFでjarファイル内のものを置き換えてください。

なお私は今後も個人的にSpotBugs開発に携わっていく予定です。BCEL自体がスレッドアンセーフらしく一筋縄ではいかないようですが、マルチスレッド化を進めていきたいと考えています。今後ともよろしくお願いします。

FindBugsの後継としてのSpotBugsの紹介

このエントリは「Announcing SpotBugs as FindBugs successor」の意訳です。一部、明らかなURLの誤りを修正し、可読性のため強調を施しています。


皆さんこんにちは、

このメールはこのメーリングリストにおける私の最後の投稿であり、また昨年のこちらの投稿の続きです。
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html

TL;DR: FindBugsプロジェクトはプロジェクトリードが管理者権限を移管しないままプロジェクトを離れ、また1年以上応答がなくなったため停止しました。SpotBugsプロジェクトがその後継であり、バージョン3.1.0 RC5を既にリリースしています。ASM6の安定バージョンがリリースされしだい、SpotBugsの3.1.0 RC6そして3.1.0安定バージョンがリリースされる予定です*1

私が前述のメールを書いてから数名の有志がプロジェクトに参加して、私たちがプロジェクトが生き残るチャンスをものにできるよう助けてくれました。FindBugsという名称は商標であることから他の名称を使う必要が生じたため、新しいプロジェクトはSpotBugsと名付けられました。コードも新しいリポジトリに移され、ホームページ,メーリングリスト,バグトラッカーなどもGitHub上に用意されました。

私たちはASM 6のリリースを待ってSpotBugsの3.1.0 RC6と3.1.0 finalバージョンをリリースします、これは今月中に実現する見込みです。

SpotBugs 3.1.0 RC6がリリースされたら(このバージョンは最後のRC版になるでしょう)、私たちはコマンドライン,Antタスク,Mavenプラグイン,GradleプラグインEclipseプラグインそして新しいマニュアルを提供します。

FindBugs 3.0.1からの変更点はこちらに一覧化されています:
https://github.com/spotbugs/spotbugs/releases

注目すべき変更点は以下のとおりです(私が何かを忘れていたらすみません):

  • リリースされたばかりのJava 9で動作します
  • 実行にはJava 8かそれより新しいJavaが必要です
  • EclipseプラグインMavenプラグインそしてGradleプラグインのIDが変わりました*2
  • BCEL 6.1とASM 6を使用しています
  • GradleプラグインはGradle 4かそれより新しいバージョンで動作します
  • EclipseプラグインEclipse 4.6*3かそれより新しいバージョンで動作します
  • プロジェクトのビルドにはGradleを使っています
  • 新しいマニュアルはreadthedocsでホストされています
  • 新しいプラグイン開発者向けテスト機構を備えています
  • Travis CIを使ったプルリクエストの検証を行います
  • その他コミュニティによる多数のバグ修正と貢献が含まれます

我々はすべてのFindBugsユーザが大きな問題なくSpotBugsを使えるよう望んでいます。マニュアルのマイグレーションガイドを見てください。我々はまた皆さんがテストやバグ報告や貢献を通じてSpotBugsプロジェクトを支援してくれることを期待しています。実際のところ、コミュニティの助けがなければ開発を続けることはできません。

もちろん上述のメーリングリストやイシュートラッカーの購読も忘れないでください。

*4はまたSpotBugsを助けてくれたすべての人々に感謝の言葉を伝えたいです。GitHubの貢献者一覧を見てください。

特にJuan Martín Sotuyo DoderoとKengo TODA*5。彼ら二人がいなければ今日のSpotBugsプロジェクトは存在しなかったでしょう。二人ともありがとう!

これがこのメーリングリストでの最後の言葉です:私はこのようなことが起こるとは想像していなかったし、このようなことを言うことは非常に悲しいのですが……さようならFindBugs!あなたは10年間に渡り、何百万人もの開発者を助けてくれました。Bill、David、こんなに素晴らしいツールをありがとう。こんなアナウンスをしてしまって申し訳ないけど、ショーは続かなければならないんだ。

はじめまして、SpotBugs!

*1:訳注:3.1.0 RC6は既にリリースされています

*2:訳注:原文には記載がないがGradleプラグインもIDが変わっている

*3:訳注:Eclipse Neonのこと

*4:訳注:投稿者Andrey Loskutov氏のこと

*5:訳注:訳者のこと

javadoc.ioのクローンをreactorで実装した

また技術キャッチアップ用のプロジェクト作りました。今回使いたかったのは以下の4つ:

  • spring-boot v2.0(リリース前)
  • spring-webflux v5.0(リリース前)
  • selenide v4.5
  • checker framework v2.2

Springは5.0リリース前にマイルストーン版を使って感覚を見たかったため、特にreactorとRxJavaの違いを確認したかったため。 selenideはユースケースを見たことが無かったのでなんの役に立つのか肌感覚を持つため。 checker frameworkは公式ドキュメントに色々不明点がある*1ので、(今までやってきたライブラリやCLIツールではなく)自走するウェブアプリで色々確かめたかったためです。

以下所感をまとめておきます。

reactorによるウェブアプリ実装について

vert.xでも感じたことですが、reactive-streamsを使ってのウェブアプリ実装は十分に可能なものの、どの程度ペイするのかよく分からないというのが実情です。 外部サーバとのI/Oが処理のほとんどとなりやすいウェブアプリにおいて非同期I/Oを短く簡潔に扱えるというのは利点ですが、リアクティブに処理を書く必要性・Backpressureの利点をきちんと享受したいケースがどの程度あるかというと疑問という感じでしょうか。 これについてはそれなりの負荷がかかるサービスで比較検証する必要がありそうです。ab等を使った負荷検証をしてみます。

また静的解析ツールの支援を受けられないのはなかなかつらいなと思いました。 subscribe()時に正常系のconsumerだけ設定したためにエラーに気づけなかったケースとか、Mono.create()Mono.from()の違いを知らずonNext signalを掴み損ねたケースとか、習熟すればすぐに見つけられるがそうじゃないとかなり厳しい「書き方の問題」が多数ありました。年月が解決する問題ではありますが、現時点では業務用途はだいぶきつい印象です。

selenideでできることはコード短縮だけでないという話

Selenideを使ってみて「あれこれって大してコード量減らないのでは……?」と思ったのでつぶやいた結果、公式アカウントに突っ込まれました。

ブラウザのレンダリングを待つようなコードをいちいち埋めないでいいというのは、確かに大きな利点です。特にSeleniumを使ったテストの経験が浅い開発者は、気軽に Thread.sleep(long) してしまいテストを遅くする傾向にあります。コードレビューで指摘し育てるのも手ですが、Selenideのようなソリューションで統一的に解決してしまうのは手でしょう。

ただリダイレクト周りの検証とか、いまいち書き方がわからずWebDriverを直接叩くケースはまだまだありそうな感じでした。これだけ知っていればSeleniumについて気にしないで良い、というモノでは無さそうです。

checker framework

ちょっとまだfalse-positiveや価値の低い解析結果が多い印象です。Java標準APIはデータベースが整ってきているようですが、ライブラリ側(今回で言えばreactor含むSpring Framework)のデータベースが無いため、Nullableを許容するAPIでも「ここはNonnullだから!null渡さないで!」とコンパイルエラーになることが多いです。結局SuppressWarningをつけて回避しています。

彼らが配布するQualifierの認知度が上がり利用されるようにならないと、まだ積極的な導入は難しそうという印象を持ちました。

*1:サンプルプロジェクトがcompileOnlyではなくcompileでchecker frameworkに依存してるのはなぜ?等

SpotBugsプラグイン実装方法2017

過去にFindBugsプラグインの実装方法について記事にしたとおり、FindBugsプラグインの実装には複雑なハックが必要でした。特にfindbugs.xmlやmessages.xmlなどのメタデータ管理が煩雑でした。

これがSpotBugs 3.1.0-RC3ではある程度楽になっているので、シンプルになった方法をここにまとめておきます。

プロジェクトの雛形を作る

archetypeがコミュニティから提供されるようになりました。これを使えばプラグイン開発の知識がなくてもすぐにプロジェクトを作成できます。

github.com

使い方は他のmaven archetypeと同じで、archetype:generate実行時にarchetypeのgroupId, artifactIdそしてversionを指定するだけです。現状バージョン0.1.0が最新なので、以下のコマンドを実行してください:

$ mvn archetype:generate \
    -DarchetypeArtifactId=spotbugs-archetype \
    -DarchetypeGroupId=com.github.spotbugs \
    -DarchetypeVersion=0.1.0

バグとして検出すべきケースを実装し、単体テストを回す

プロジェクト生成に成功すると、src/test/javaに2つのクラスが見つかるはずです。

これらを実際に解析して結果を確認しているテストケースもあります。

このテストケースは、SpotBugsが出しているtest-harnessモジュールを使っています*1SpotBugsRuleというクラスがキモで、これを使って実際の.classファイルを解析し結果を確認できます。assertion用のMatcherクラスも提供されているので、hamcrestを使ったテストも書きやすいです。

     @Rule
     public SpotBugsRule spotbugs = new SpotBugsRule();
     @Test
     public void testIssuesAreFound() {
         Path path = Paths.get("target/classes/my/company/AnalyzedClass.class")
         BugCollection bugCollection = spotbugs.performAnalysis(path);

         // There should only be exactly 1 issue of this type
         final BugInstanceMatcher bugTypeMatcher = new BugInstanceMatcherBuilder()
                 .bugType("NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE").build();
         assertThat(bugCollection, containsExactly(bugTypeMatcher, 1));

         final BugInstanceMatcher bugInstanceMatcher = new BugInstanceMatcherBuilder()
                 .bugType("NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE")
                 .inClass("AnalyzedClass")
                 .atLine(25)
                 .build();
         assertThat(bugCollection, hasItem(bugInstanceMatcher));
     }

以前はプラグインを実際に使ったテストをするためにはfindbugs-maven-pluginを使ってインテグレーションテストを回すしか方法がありませんでしたが、この手法ならより高速にテストを回せます。また test-driven-detectors4findbugsと違って公式なので、今後のSpotBugsの更新にも追随できるはずです*2

メタデータを作成する

まずbugrank.txtは現状必要ないようです。無くてもプラグインはビルドできます。そもそもBugRankという概念はこの論文でやこのページ紹介されている通り、SonarQubeのSeverityのようなもので、priority (confidence)とは全く別の概念です。が、果たしてそれがどの程度浸透しているのか……。SpotBugsが使うpriorityやpriority (confidence)のことは忘れてSonarQubeのSeverityだけ使うのが、運用も回しやすいと思います。

ので、全体的な情報を提供するfindbugs.xmlと、ユーザ向けメッセージを管理するmessages.xmlだけ作成すれば十分です。プロジェクトの雛形にはこれらが既に作成されているので、それを参考にコピペで要素を増やしてください。

番外編:SonarQubeプラグインを作成する

SonarQubeプラグインsonar-packaging-maven-plugin を使ってパッケージできます。sonar-findbugsと拙作findbugs-slf4jが参考になります。

キモはfindbugs-pluginバージョン3.5への依存を宣言することです。このバージョンはSpotBugs 3.1.0-RC2を使っているため、SpotBugsに依存したプラグインを書くには必須です。

なおsonar-findbugsバージョン3.5はpre-releaseバージョンで、まだSonarQubeのUpdate Centerでは配布されていません。使用する際はGitHubのリリースページからjarを落としてきて手動インストールする必要があります。

またSonarQube用のrule.xmlを生成する必要があるのですが、これは雑ですがMavenプラグインを作ったので使ってもらえればと思います。Groovy好きな方はsonar-findbugsのコードを参照しても良いでしょう。

まとめ

以上でSpotBugsプラグインを実装してSonarQubeも含めた運用を回すことができるはずです。 まだ各種親Detectorを学習する手間は必要ですが、5年前に比べてだいぶマシにはなりました。

追記:公式かつ英語のドキュメントもできました。

*1:find-sec-bugsからコードを持ってきて作られたもの

*2:test-driven-detectors4findbugsはFindBugs 1.3.9〜2.0.2にしか対応していなかった

JJUG CCC 2017 Springでセッション&LT参加してきました

前回のエントリでの宣言通り、本日のJJUG CCCでセッション発表してきました。発表のスライドと動画が後日、下記会社のアカウントから共有されると思います。公開されたらこの記事で紹介します。

昼休み明けすぐの発表でしたが、だいたい140名ほど参加いただけたようです。全日程では1,032名の参加があったそうですが、セッション発表時点では700名近く参加されていたらしいので、全体の2割近い方が参加されていたことになりますでしょうか。FindBugs知名度を改めて感じました。

静的解析ツール初心者の聴講者はゼロだったので、最初の方の静的解析ツールのメリットについてはかなり端折り、突っ込んだ内容を厚めに話しました。プラグイン開発デモができなかったのは残念でしたが、spotbugs-archetypeを使っていただければある程度は伝わる……といいなぁと思います。

また懇親会でのLTでも2分ほど話してきました。こちらは純粋にSpotBugsの中の人としての参加です。SpotBugs 3.1.0 RC2はわりと安定していますので、皆さんも使えるところで試してフィードバックいただければと思います。

追記(2017/05/24)

セッションのスライドが公開されました。

www.slideshare.net