くりにっき

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

capistrano-itamae v1.0.0をリリースした

capistrano itamae gem

github.com

リリースノート

https://github.com/sue445/capistrano-itamae/blob/master/CHANGELOG.md#v100

非互換の変更

itamae_ssh の2番目の引数がキーワード引数になりました

  • Before (v0.x): itamae_ssh "recipe.rb", "xxxxx"
  • After (v1.0.0+): itamae_ssh "recipe.rb", options: "xxxxx"

変更の経緯

itamae_ssh メソッドに3つ目の引数を追加したくなったんですが、既存の引数に追加する形だと分かりづらくなりそうだったのでキーワード引数に変えました。

この辺がBreaking changeするかどうか悩んでた時の僕の苦悩です。

機能追加

itamae_ssh メソッドに environment 引数を追加して、 itamae ssh 実行時に任意の環境変数を渡せるようにしました。（実際これをしないとrbenvではなくsystem側のbundlerを呼ぼうとして変な挙動になって困ってた）

itamae_ssh "recipe.rb", environment: { path: ENV["PATH"] }

第1回CircleCI ユーザーコミュニティミートアップに登壇しました #circlecijp

CircleCI

第1回CircleCI ユーザーコミュニティミートアップ で登壇した時の発表資料です。

circleci.connpass.com

発表資料

スライド板

sue445.github.io

markdown版

github.com

いいはなし

いつもの

写真だと分かりづらいですが下記のフルグラ嫁T着用での登壇でした。

www.instagram.com

circleci-ruby-orbs v1.4.0をリリースした

CircleCI

リリースノート

https://github.com/sue445/circleci-ruby-orbs/blob/master/CHANGELOG.md#v140

今まで Gemfile.lock がコミットされているリポジトリでしか使えませんでしたが、v1.4.0ではgemのように Gemfile.lock をコミットしていないリポジトリに対応しました！

使い方

Gemfile.lock をコミットしていない場合、ruuby-orbs/bundle-install の引数に with_gemfile_lock と gemspec_name を渡してください。

# .circleci/config.yml
jobs:
  rspec:
    docker:
      - image: circleci/ruby

    steps:
      - checkout

      - ruby-orbs/bundle-install:
          with_gemfile_lock: false
          gemspec_name: "yourgem"
      # or
      - ruby-orbs/bundle-install:
          cache_key_prefix: "v1-bundle"
          bundle_jobs: 4
          bundle_retry: 3
          bundle_path: "vendor/bundle"
          with_gemfile_lock: false
          gemspec_name: "yourgem"
          bundle_clean: true
          bundle_extra_args: ""

      # Add your job (e.g. rspec, rubocop)
      - run: bundle exec rspec

エピソード

今回の実装自体はサクッといったのですが、orbのインテグレーションテストが謎のエラー *1 で失敗するという事象にハマっていました。

CircleCIのバグのような挙動だったので最終的にバグレポートを上げてバグを修正してもらい、ようやくv1.4.0をリリースできました。

discuss.circleci.com

余談

https://circleci.com/orbs/registry/ がPopular*2でソートできるようになっていたのですが、sue445/ruby-orbsが3rdパーティ製のorbの中で上から3番目でした！

f:id:sue445:20190124233153p:plain

ただし自分の上にいるiynereとeddiewebbはCircleCIの社員なので、社員製のorbを除けばsue445/ruby-orbsが実質1番ですｗ

*1:1つのorbの中でconditional stepsをたくさん定義してた時にビルド時にエラーになる

*2:プロジェクトからの参照数かビルドでの実行数辺りだとは思うけど不明

index_shotgun v1.0.0とactiverecord-simple_index_name v1.0.0をリリースした

Ruby gem

pixela v1.0.0 に引き続き今年2つ目と3つ目のメジャーバージョンアップ。

経緯

両方のgemともここ数年特に機能追加とかはしてないのですが、RubyやRailsの新しいバージョンが出る度に無邪気にTravis CIのマトリクステストの軸を増やしていったら気づいたらビルド時間が膨大になって色々とつらくなったので、新年ということでバッサリ古いバージョンを切ることにしました。

あとはbundler v2がRuby 2.3以降必須になったのも大きいかな。

両方ともRuby 2.2系以下とRails 4.2系以下のサポートを切っただけで、プロダクトコードの変更は特にないです。（rubocopで細かい整形をしたくらい）

ビルド時間の推移

index_shotgun

https://github.com/sue445/index_shotgun/blob/master/CHANGELOG.md#v100-20190106

1ビルド辺りのジョブ数 ビルド時間（直列） ビルド時間（5並列）
Before 75 2時間 30分
After 45 1時間弱 20分弱

activerecord-simple_index_name

https://github.com/sue445/activerecord-simple_index_name/blob/master/CHANGELOG.md#v100

1ビルド辺りのジョブ数 ビルド時間（直列） ビルド時間（5並列）
Before 41 1時間 20分
After 17 37分 10分

備考

  • 上で5並列と書いているのはリポジトリ単位ではなくorganization（namespace）単位での上限なので、一度index_shotgunやactiverecord-simple_index_nameのビルドが始まると僕がメンテしてる他のリポジトリのビルドが実行待ちになります。（つらい）
  • 40個くらいあるgemの .travis.yml を全部修正するとビルドが全部終わるのにだいたい一晩かかります。（つらい）

ビルド時間短縮以外のメリット

  • Ruby 2.3以降前提にしたことでSafe navigation operator（&.）、Hash#dig 、 <<~ 形式のヒアドキュメントなどが解禁
    • Hash#compact を使いたい場面がちょいちょいあるので個人的にはRuby 2.3系も早くサポート切りたい思い
  • 古いRubyやRailsを考慮した分岐が不要になった

pixela v1.0.0をリリースした

gem Ruby Pixela

リリースノート

https://github.com/sue445/pixela/blob/master/CHANGELOG.md

新機能はPixela v1.6.0のoptionalData の対応のみ。

github.com

メジャーバージョンアップですが、今回の破壊的変更は既にEOLになってるRuby 2.2系以下のサポートを明示的に切ったことだけなのでそんなに影響はないかと思ってます。（今までもなんとなくRuby 2.1以上では動いてたつもりだけど今回の変更でSafe navigation operator（&.）を使いたかったので2.3以降にしたかった）

gitlab_awesome_release v1.0.2をリリースした

Ruby GitLab

https://gitlab.com/sue445/gitlab_awesome_release/blob/master/CHANGELOG.md#v102

Ruby 2.6.0で動かすとSEGVになるのでエラーにならないようにしました。

SEGVになる件は https://bugs.ruby-lang.org/ で報告してtrunkでは修正済なので、2.6.1では直っているはず。

bugs.ruby-lang.org

【追記あり】Travis CIでMJITを有効にしたビルドマトリクスを作る

Ruby

何番煎じか分からないけど自分用メモ

tl;dr;

.travis.yml に下記のようなものを書くだけ

script:
  - RUBYOPT=$RSPEC_RUBYOPT bundle exec rspec

matrix:
  include:
    - rvm: 2.6
      env: RSPEC_RUBYOPT="--jit"
    - rvm: ruby-head
      env: RSPEC_RUBYOPT="--jit"

実行結果

https://travis-ci.org/sue445/rubicure/builds/473290010

f:id:sue445:20181229205640p:plain

ビルドスクリプト内で RUBYOPT="--jit" bundle exec rspec とかしてもいいんですが、それだとビルドがコケた時にJIT起因の問題なのかそうじゃないのかが分かりづらくなるのでこっちを推奨です。

あと、

rvm:
  - 2.6
  - ruby-head

を書いていた場合に、MJIT無しのビルドとMJIT有りのビルドが両方実行されて、MJITの有無でどれくらいビルドの時間が変わっているか比較しやすいというメリットもあります。

2019/6/19 追記

6/18くらいのCIからRuby 2.6系にも関わらず invalid option --jit というエラーが起きるようになりました

$ export RUBYOPT="--jit"

$ rvm use 2.6 --install --binary --fuzzy

ruby: invalid option --jit  (-h will show valid options) (RuntimeError)

https://travis-ci.org/sue445/omniauth-chatwork/jobs/547082488

いやいやそんなことないだろーと思ってたら、rspecの実行よりも前にエラーが起きているのでどうやらビルドの初期化のタイミングでTravisの中のRubyスクリプトが実行されていて、そいつがRuby 2.6未満なのが原因のようでした。

.travis.yml で RUBYOPT を上書きしないようにしたら --jit でコケないようになりました

github.com