くりにっき

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

Travis CIのビルド終了後にPixelaで草を生やす

mike-neck.hatenadiary.com

ちょっとしたことですが、 pixela-java-client の CI をまわした回数を Pixela で数えてみることにしました。

に影響されてやってみました。たぶんTravis CI以外でもできるはず

tl;dr;

webhook作成後に .travis.ymlに下記を書く

after_script:
  - if [ "$PIXELA_WEBHOOK_URL" != "" ]; then curl -X POST $PIXELA_WEBHOOK_URL -H 'Content-Length:0'; fi

前置き

Travis CIではテストの前後などに任意の処理を差し込めるのですが、何が使えるかは下記に全部載ってます

docs.travis-ci.com

このうちビルド終了後の処理は

  • after_success
  • after_failure
  • after_script

ですが、after_successafter_failureは名前の通りビルド成功時と失敗時のみ実行されるやつなので今回はビルド結果に関わらず実行したいのでafter_script` を使います

手順

グラフとwebhookを作成

拙作の pixela gem を使うとこんな感じ。

require "pixela"

client = Pixela::Client.new(username: ENV["USERNAME"], token: ENV["TOKEN"])

client.graph("pixela-gem-ci").create(name: "CI activity of pixela-gem", unit: "build", type: "int", color: "shibafu", timezone: "Asia/Tokyo")

client.create_webhook(graph_id: "pixela-gem-ci", type: "increment")

create_webhook の戻り値に webhookHash が入ってるので忘れずにコピペしておきます

.travis.yml修正

after_script:
  - if [ "$PIXELA_WEBHOOK_URL" != "" ]; then curl -X POST $PIXELA_WEBHOOK_URL -H 'Content-Length:0'; fi

.travis.ymlにwebhookのURLをベタ書きするとforkされた先のリポジトリでも草が生えるのが嫌だったので、環境変数が登録されてる時のみPOSTするようにしています。

TravisCIに環境変数を登録する

Settingsに https://pixe.la/v1/users/【USERNAME】/webhooks/【webhookHash】 の形式でwebhookのurlを登録する

f:id:sue445:20190218234444p:plain

READMEとかに草を貼る

こんな感じ

[![CI activity of pixela-gem](https://pixe.la/v1/users/sue445/graphs/pixela-gem-ci)](https://pixe.la/v1/users/sue445/graphs/pixela-gem-ci.html)

グラフにpurge_cache_urlsを登録する

GitHubに画像のURLを貼ると自動的にCDN経由のURLになってしまいwebhookで草を生やしてもGitHub上に反映されないため、CDNのURL(https://camo.githubusercontent.com/〜)を purge_cache_urls に登録してやる必要があります。

client.graph("pixela-gem-ci").update(purge_cache_urls: ["https://camo.githubusercontent.com/XXXXXXXXXXXXXXXXXX"])

purge_cache_urls の仕組については下記を参照

github.com

対応時のPR

github.com

実際にできたやつ

f:id:sue445:20190218233502p:plain

pixe.la

僕がRubyKaigiのCFPを書く時に意識したり実践したこと

というわけで RubyKaigi 2019 のCFPが採択されました!!!

実際に採択されたCFPがこちらになります。

https://www.pixiv.net/fanbox/creator/2348843/post/258661

ただ、完全ネタバレになるので今は限定公開にしてます。(登壇後に全体公開します)

実際にCFPを通すにあたってむっちゃ意識してたことがあるので忘れないようにメモ

前提

  • RubyKaigi 2019の開催地は福岡
  • 僕の出身も福岡
  • 僕の所属してるピクシブも福岡オフィスがある *1
  • だったら僕が登壇するしかないじゃん???みたいな感じで、RubyKaigi 2018終了直後から2019に登壇することを意識してました。
  • とはいえ過去2回出してどっちもCFP不採択だったので、同じことをやっても同じ結果になることは分かっていたので新しい試みをすることにしました

1. CFPを2本以上書いた

採択されたのを含めて3本くらいは書いてます。

ただ、今回出した以外の残り2つは書いてる途中で違和感があるというか、なんかCFPとして弱いなあと思って8〜9割くらい書いたところでボツってるので実際に応募したのは今回の1本だけですが。

余談ですが普段5〜10分のLT慣れしてるせいで細かいネタはいくらでも出てくるんですが、40分ネタとなると大変ということを痛感しました。。。

この辺のギャップは昔見た id:daiksy さんの下記ツイートが参考になりました。(とはいえ複数のLTを1つにまとめるのも結構難しかったw)

2. 実際に採択されたCFPを参考にした

だいたいこの辺を参考にしました

今回のCFPを一通り書いた後に上記CFPを読んで、完全に絶望して全部書き直しました。

特に id:onk さんのCFPをだいぶ意識したので今度銀座Railsで会った時にお礼言わないとw

3. 他の人にレビューしてもらった

今までこれといってレビューしてもらっていなかった(と思う)ので、今回は社内でレビューしてもらいました。

特に @igaiga555 さんは RubyWorld Conference 2018 のCFPも採択されていたので心強さしかなかったです。

レビュー後に2割くらい加筆しました。

余談:現在の心境

さっさと3月分のスライドを完成させてRubyKaigiのスライドに着手しないと、、、

*1: RubyKaigi 2018の時点でピクシブに内定決まってた

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

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

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

circleci.connpass.com

発表資料

スライド板

sue445.github.io

markdown

github.com

いいはなし

いつもの

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

www.instagram.com

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

リリースノート

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_lockgemspec_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番ですw

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

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

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

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

経緯

両方のgemともここ数年特に機能追加とかはしてないのですが、RubyRailsの新しいバージョンが出る度に無邪気に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系も早くサポート切りたい思い
  • 古いRubyRailsを考慮した分岐が不要になった

pixela v1.0.0をリリースした

リリースノート

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以降にしたかった)