SideCI Blog

自動コードレビューサービスSideCIを提供している株式会社アクトキャットのコーポレートブログです。



SideCIでMisspellが使えるようになりました🎉

こんにちは。id:Pocke です。

SideCIで新しい解析器がご利用いただけるようになりましたので報告させていただきます。
今回追加された解析器は、Misspellです。Misspellを使用することで、ソースコードやその中のコメント、ドキュメントなどに含まれる英単語のタイプミスを検出することができます。

f:id:Pocke:20171017191528p:plain

SideCIでの使い方

SideCI上で設定を行っていただくことで、Misspellをお使い頂くことが可能です。

まず、Misspellを有効にしたい対象のリポジトリの設定画面を開いてください。

f:id:Pocke:20171017191614p:plain

つぎに、設定画面の解析ツール選択の中の、Misspellにチェックを入れてください。

f:id:Pocke:20171017191629p:plain

これで、次回の解析からMisspellが使用されるようになります。

US / UK のロケールの選択や、無視したい単語などがある場合、sideci.ymlをお使い頂くことで設定が可能です。 詳しくは、こちらをご覧ください。 https://docs.sideci.com/tools/misspell.html

注意点

なお、Misspellはアビシニアンモードのみの提供となっております。 クラシックモードをお使いのお客様は、アビシニアンモードに切り替えの上Misspellをお使いください。 また、クラシックモードは今月末の2017/10/31に終了予定となっておりますので、クラシックモードをお使いのお客様はお早めにお切り替えください。

blog-ja.sideci.com

また、何かありましたらお気軽にお問い合わせください。

SideCIでのクラシックモード廃止のお知らせ

SideCIは、2017年10月31日をもちまして、サービスの正式リリース時より稼働しておりました、クラシックモードを廃止することをお知らせいたします。

  • お客様にご登録いただいておりますリポジトリは、11月1日以降すべて強制的に新規モードに切り替わります
  • 新規モードは既に稼働しており、2017年9月6日時点で移行することが可能です
    • 新規モードは完全な互換性を保つものではありません
    • 一部の解析器の設定に問題が生じることがあり、また開発チームでのレビューのワークフローに変更が必要となることがあります

新規モードへの移行に伴う問題の発生を防ぐため、お客様ご自身での、前もっての移行をお願いいたします。

クラシックモードについて

SideCIでは、現在アビシニアンモードとクラシックモードという2つの異なるインターフェイスをそれぞれ提供しております。

f:id:a_ksi19:20170906160053p:plain アビシニアンモードのスクリーンショット

f:id:a_ksi19:20170906160109p:plain クラシックモードのスクリーンショット

現在、「クラシックモードのスクリーンショット」と同様の画面でSideCIをお使いになっている場合、アビシニアンモードへ移行していただく必要があります。

アビシニアンモードでは以下の点が、クラシックモードと比較した場合の主な改善点です。

  • より安定した解析システム
  • Pull Request commits に対してより向上した差分の追跡
  • commit やその解析結果の一元的な管理
  • 解析ログの表示

これらの詳細については、以下の弊社記事をご覧ください。

さらに、新たなSideCIでは、下記に挙げる点においてクラシックモードと異なります。

  • 自動修正機能のサポート廃止
  • Commit Status制御の簡略化

自動修正機能は、SideCIにおいて今後サポートする予定はございません。もし自動修正を行う場合は、お客様のローカル環境で実行してください。

Commit Statusの制御は簡略化され、ツールによってにCommit Statusへの影響を設定することはできなくなりました。SideCIの解析において問題が発見された場合には、常にCommit Statusが赤に設定されます。

発見された問題を修正せずにマージするには、SideCIのWebアプリから「クローズ」操作を行ってください。明示的なクローズの操作の導入により、開発者がその問題についてどのように考えているのかが、レビュアーに伝わるようになりました。

移行方法

アビシニアンモードへの切り替え

モードの切り替えは、リポジトリ設定画面より行うことができます。

f:id:a_ksi19:20170906160133p:plain

モード切り替え後、新たにPull Requestを開くか、既存のPull Requestに新たにcommitを積むとアビシニアンモードでの解析が実行されます。

Pull Reqeustへの指摘のコメント

アビシニアンモードは、一元的な解析結果の管理を行うために設計されていますが、設定することにより、クラシックモードのように、Pull Requestに対してコメントを行うことができます。こちらの詳細は以下の記事をご覧ください。

解析における非互換性について

2つのモード間における各解析器は、概ね互換性を保っておりますが、一部非互換な部分があります。これにつきましては、以下のドキュメントをご覧ください。

もし、不整合な点や不具合を見つけた場合、お知らせいただけますと幸いでございます。

解析実行時のトラブルシューティング

f:id:a_ksi19:20170906160250p:plain

解析実行時、解析の実行が失敗したり、意図しない挙動になった場合、解析ログを表示することでトラブルシューティングを行うことができます。上記画像は、Pull Requestの解析結果画面において、解析器名の横にある「Trace」をクリックすることで確認することができます。

f:id:a_ksi19:20170906160222p:plain

クラシックモードを使いたいお客様は、リポジトリを設定画面より戻すことが可能です。ただし、この場合でも10月31日を最後に強制的にアビシニアンモードに切り替わります。

f:id:a_ksi19:20170906160259p:plain

まとめ

  • クラシックモードは2017年10月31日をもって廃止します
  • クラシックモードをお使いのお客様は予め、モードの切り替えをお願いします

すべてのリポジトリは、11月1日以降自動的にクラシックモードから切り替わります。しかし、自動的なモード移行はお客様の開発フローを破壊的に変更してしまう可能性があるため、お客様各位の前もっての移行をお願いいたします。

SideCIはPull Requestにコメントできるようになりました

SideCI は従来、Pull Request を解析し、指摘があった際はコミットステータスを fail にして、sideci.com 上で指摘事項を確認し、対応していただいておりました。今回、それに加えて新たに Pull Request にコメントを行う機能を追加しました。これにより、Pull Request ページを離れることなく、より簡単に解析器が指摘した内容を確認することができます。

f:id:a_ksi19:20170831165847p:plain

積極的に指摘する Querly のような解析器や、細かく指摘するために厳しく設定した解析器を利用する場合、コメントされる指摘事項に多くの偽陽性が含まれることがあります。これは、GitHub 上の Pull Request のページに多くのコメントがつくことを意味しており、指摘された内容を直すのか無視するのかを注意深く確認する必要があります。この場合は、必要に応じて sideci.com からクローズするなどの対応を行うことをおすすめいたします。

指摘数が多い場合、それらの指摘はサマリとしてまとめられ、以下のようにコメントされます。

f:id:a_ksi19:20170831165922p:plain

なお、この機能はリポジトリ設定画面より設定することができます。

f:id:a_ksi19:20170831165946p:plain

また、RuboCop、ESLint、PHP_CodeSniffer など、日本語化が行われている解析器を利用していて、指摘する際の言語を日本語に設定している場合、Pull Requestへのコメントは日本語で行われます。 ※ 一部の指摘については翻訳されていない場合もございますので、予めご了承ください。

Goのソースコード解析に標準ツールのgo vetを使ってみましょう

企業内においてGoを利用するケースが増えています。コンパイル系であり静的型付けの言語で、実行速度も速いのが特徴です。さらに仕様がシンプルなので習得が容易、かつ書かれたプログラムはマルチプラットフォームで動作します。

人気が出るに従ってチームでGoプロジェクトを進めるケースも多くなるでしょう。そうした中でコードの品質を保ち、保守性を良くするために、ソフトウェアを使ってコードをチェックしましょう。。幾つかのソフトウェアがありますが、今回はGoに標準で組み込まれているgo vetを紹介します。

go vetの使い方

go vetは go tool vet [directory] といった指定方法で実行します。directory はGoのソースコードが入ったディレクトリを指定します。

$ go tool vet path/to/go/project

実行すると、問題のある箇所について指摘が出力されます。

$ go tool vet ./alecthomas/gometalinter/
adjcmartix.go:85: suspect or: char != "" || char != " "
main.go:55: arg usage in Fprint call is a function value, not a function call
resolve.go:161: unreachable code
sparse.go:58: _m might be too small for shift of 32

後はこの指摘事項に沿ってソースコードを修正していくだけです。

ヘルプ

go vet のヘルプは go doc cmd/vet で出力できます。

$ go doc cmd/vet
Vet examines Go source code and reports suspicious constructs, such as
Printf calls whose arguments do not align with the format string. Vet uses
heuristics that do not guarantee all reports are genuine problems, but it
can find errors not caught by the compilers.

It can be invoked three ways:

By package, from the go tool:

    go vet package/path/name

vets the package whose path is provided.

By files:

    go tool vet source/directory/*.go
  :

オプションについて

解析する項目をオプションで指定できます。デフォルトでは -all が指定されており、すべての項目をチェックを実行してくれます。例えば、到達しないコードのみを見つける場合は -unreachable を使います。

$ go tool vet -unreachable ./alecthomas/
alecthomas/gometalinter/_linters/src/golang.org/x/text/unicode/cldr/resolve.go:161: unreachable code
alecthomas/gometalinter/vendor/gopkg.in/yaml.v2/decode.go:123: unreachable code

他にポインタを数値に変換する際に unsafe.Pointer を使っていると警告を出せる -unsafeptr オプションがあります。

$ go tool vet -unsafeptr ./alecthomas/
alecthomas/gometalinter/_linters/src/golang.org/x/tools/go/ssa/interp/external.go:302: possible misuse of unsafe.Pointer

// コードは次のようになっています
if pc != 0 {
  fn = (*ssa.Function)(unsafe.Pointer(pc)) // indeed unsafe!
}

基本的にはすべての項目をチェックで良いと思いますが、必要に応じてフラグを指定して、必要な種類の項目・解析のみを実行してください。


go vet は標準的な、これまでの経験上問題と推測される点を指摘します。つまり指摘事項が必ずしも問題とは限りません。とは言えコンパイラでは問題がない内容でも指摘してくれるでしょう。内容に沿って修正することで、分かりやすいコードに仕上げられるでしょう。

Go言語用のコード解析ツールはCPUリソースを多く消費するものが多くあります。そのため、ローカルのPCで実行するには時間がかかってしまって煩わしく感じることがあるかもしれません。そんな際にはGitHubでPull Requestと連携してGo言語用解析ツールを実行する、コードレビューの自動化用のCIサービスであるSideCIがお役に立てると思います。SideCIはgo vetにも対応しています。無料トライアルがありますので、まずはお試しください

bundlerのoutdatedコマンドを使ってGemfileの古いライブラリをチェックしましょう

RubyプロジェクトではBundlerを使って依存ライブラリの管理を行うのが一般的です。ライブラリのインストールは簡単にできますが、その後適切に最新バージョンを追いかけないとセキュリティ上のリスクが発生することや、アップデートの差分が大きくなりすぎてアップデートしたくでも難しくなりがちです。

続きを読む