くりにっき

フルスタックキュアエンジニアです

【今月のgem】 gitlab_awesome_releaseというgemを作った(ついでにGitLab + GitLab CI使ってみた雑感)

gitlab_awesome_releaseについて

どういうgem ?

GitLab上のtagとMergeRequestからいい感じにCHANGELOGを自動生成するためのgemです

いい感じに自動生成されたCHANGELOG https://gitlab.com/sue445/gitlab_awesome_release/blob/master/CHANGELOG.md

(ちなみにGitHubだと GitHub Changelog Generator があります)

作った経緯

元々同様の機能を持った社内gemがあったのですが

  • 社内GitLabに依存している機能がなかったのでOSSにしたかった
  • 外に出すにはテストを書いていないとメンテがしんどい
    • gemの中でローカルのgitコマンドをたたいていたのでテストがしんどい
    • 「ローカルでgitコマンドたたいている部分を全部GitLabのAPIを呼ぶようにすればAPIの呼び出しをモックにすることでテストできるのでは!?」という発想

という感じでgemを作成しました

社内gemを元にしたといってもgemの設計思想とコマンド名以外は完全にフルスクラッチです (ノ∀`)

GitLabでアプリを作っている人はリリースノートの作成が捗るのではないかと思います。

余談ですがPullRequestやMergeRequestのタイトルをそのままCHANGELOGにすることを心がけていると、「NameError出ていたのを修正」のような利用者にはどうでもいい内部実装に関するタイトルではなく、「○○の時にエラーになっていたのを修正」「○○のような機能を実装」のような利用者視点で読みやすいタイトルになるので分かりやすくなると思います。

頑張ったところ

全てのオプションをサブコマンドの引数と環境変数の両方から読み込めるようにした

サブコマンドによって受け取れる引数の種類は違いますが

  • --gitlab-api-endpoint or GITLAB_API_ENDPOINT: GitLab APIのエンドポイント:
  • --gitlab-api-private-token or GITLAB_API_PRIVATE_TOKEN: GitLabのprivate token *2
  • --gitlab-project-name or GITLAB_PROJECT_NAME: Changelogを生成するプロジェクト名
  • --from-tag or FROM_TAG: 開始タグ
  • --to-tag orTO_TAG: 終了タグ
  • --filename or FILENAME : 出力先(省略時はコンソールに出力)
  • --allow-tag-format or ALLOW_TAG_FORMAT: バージョンとして受け付けるtagのフォーマット
  • --log-level or LOG_LEVEL: ログレベル

のように、サブコマンドの引数と環境変数を両方受け付けるようにしています

このような仕様にしているのはprivate tokenのようにコンソールに直接typeしたくないオプションもあるし、かといってオプションによって引数だったり環境変数だったりと違うのは紛らわしいので両方受け取れるようにしています。

さらに、~/.env.gitlab や カレントディレクトリの .env.gitlab環境変数を設定しておくことでコマンド実行時にこれらのファイルから環境変数を読み込みます。至れり尽くせり!

markingが見やすい

CHANGELOGからは対象のMergeRequestにリンクが貼られますが、markingコマンドを使うとそのMergeRequestにバージョンのラベルをつけることができます

f:id:sue445:20151017162028p:plain

どの修正がいつリリースされたのかすごく分かりやすいと自分の中で好評です

GitLab.com + GitLab CIで開発してみた雑感

今回gemの特性上GitLab上で開発する必要があった*3ので、(社内にホスティングされていない方の)GitLab.comGitLab CI で開発することにしました

普段と違う開発ということでハマりどころというか思うところがあったので書いてみます

GitHubの周辺ツールが使えない

普段OSSでgemを作ってる時は

辺りの無料の便利ツールを使ってたのですが、GitLabだとその辺のツールがことごとく非対応だったのがつらかったです

ツールの詳細は下記エントリ参照 sue445.hatenablog.com

GitLab.comでも使えるツール

Travis CI(CIツール

GitLab CIを使う(後述)

Code Climate(静的解析)

Code ClimateはGitHubに限らず任意のリポジトリを登録できるのでGitLab.comでも使えます。ただ、その場合有料プランになってしまうので断念しました *4

参考: https://codeclimate.com/pricing

Coveralls(カバレッジ集計)

GitLab非対応。ただしGitLab CIが(Coverallsほど高性能じゃないけど)カバレッジ集計に対応している

ビルド実行時の標準出力の内容を正規表現でparseして

f:id:sue445:20151014014213p:plain

右側に表示される

f:id:sue445:20151014014218p:plain

Gemnasium(利用しているgemのアップデートチェック)

Gemnasium自体はGitLab対応してます

f:id:sue445:20151014015501p:plain

ただし無料枠だとGitHubリポジトリと違い2つまでしか登録できません

詳細:https://gemnasium.com/pricing

GitLab CIの使い勝手

GitLabと親和性高いのが強み

連携はボタンポチるだけなのでJenkinsとGitLabを連携するよりは楽でした

Jenkinsと比べたら出来ることは少ないですが *5、機能的にはWerckerやCircle CIと同じくらいのように感じました。

Runnerについて

Runner *6の仕組みは面白かったです。公式で用意されている全ユーザ共有のRunnerの他にも自分用にRunnerを登録しておくことができます。またGitLab CI自体がDocker対応しているのでRunner自体の環境構築はそんなに考えなくていいです。

stageの概念が面白い

詳しい説明は http://doc.gitlab.com/ci/yaml/README.html に譲りますが

  1. stage1でjob1とjob2を並列実行
  2. stage1のjobが全部終わったらstage2でjob3とjob4を並列実行

のような細かいジョブの制御ができます。JenkinsだとWorkflow pluginを使えば実現できますが、GitLab CIだとymlに書くだけで実現できるお手軽感がいいです。(Travis CIやCircle CIはここまで詳細な制御はできなかったはず)

GitLab.comのつらみ

たまに重い

GitHubやbitbucketに比べたら全体的にモッサリ感はありますが最近よくエラーになります (;´Д`)

*1:GitHubじゃない理由は後述

*2:APIを使うために必要なtoken

*3:自分自身のCHANGELOGをこのgemで作成することが一番のサンプルになる

*4:趣味開発で月$99はちょっと高い

*5:Jenkinsが何でも出来過ぎる説はあるw

*6:Jenkinsにおけるslaveのようなもの