rustでgemパッケージ内のコードを書く方法のメモ
Ruby 3.2に同梱されるBundlerでは、 bundle gem
に --ext=rust
とすることでrustでgemのコードを書けるようになります。
新しいものはとりあえず触ってみたいので、試してみましょう(完全にn番煎じなのですが、自分用の備忘録です)
事前準備
- rustのビルド環境
- Ruby 3.2.0(正確にはBubdler 2.4.0以上)
やってみる
rust_gem_sample
という名前のライブラリを作ってみるとしましょう。
$ bundle gem rust_gem_sample --ext=rust : # 場合によってはさまざまな質問があるので適当に答える
これで雛形ができる。
作成された rust_gem_sample
ディレクトリへ移動し、コードをさらっと眺めてみましょう。
rustのコードはC言語の場合と同じように ext ディレクトリ内に生成される。
$ tree ext ext └── rust_gem_sample ├── Cargo.toml ├── extconf.rb └── src └── lib.rs
ちなみに、生成されるサンプルコードはこんな感じ
# ext/rust_gem_sample/src/lib.rs use magnus::{define_module, function, prelude::*, Error}; fn hello(subject: String) -> String { format!("Hello from Rust, {}!", subject) } #[magnus::init] fn init() -> Result<(), Error> { let module = define_module("RustGemSample")?; module.define_singleton_method("hello", function!(hello, 1))?; Ok(()) }
define_singleton_method
でメソッドが定義されているということは、RustGemSample.hello
で呼び出せて、1つの引数を受け取るコードってことですね。
さて、ビルドするためには事前準備が必要なので、以下を修正します(これはrust関係なく、bundle gemした時に必要な一般的なもの)。
rust_gem_sample.gemspec
- TODOをURLっぽい値に書き換えておく(これをしないとビルド時にエラーになる)
- testを生成している場合、自動生成された test コード
- デフォルトのコードは失敗するようなコードになっているので、修正するなり消すなりする必要がある
これは余談ですが、久しぶりにgemspecの中身を見て source_code_uri
や changelog_uri
というのが設定できるということを知りました。RubyGemsのドキュメントを見るに、設定しておくとrubygems.orgのサイドバーにいい感じに表示してくれるっぽいですね……?
$ ./bin/setup
$ bundle exec rake
これで無事にビルドできるはずです。
ではお試しで実行してみましょう。
$ ./bin/console Ignoring rust_gem_sample-0.1.0 because its extensions are not built. Try: gem pristine rust_gem_sample --version 0.1.0 irb(main):001:0> RustGemSample.hello("hoge") => "Hello from Rust, hoge!" irb(main):002:0>
おー、うごいた!
せっかくなのでブログにしてみよーと思って書き始めたのですが、なんか、思ったより何もせず動いてしまった……(いい話)。
2021年に読んだ本
2021年は比較的本を読んだ気がします。
よく考えると、ゲームチェンジが起こったことが影響しているかもしれませんね。
ロマサガRSとニーアをやめて以来、まじで「空き時間は周回」の呪いから解き放たれて「チョット本を読むか」などの気持ちが生まれてきた
— sugamasao (@sugamasao) 2021年4月7日
読み切った本
いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか
アーサー王とかエクスカリバーとか、小さい頃から慣れ親しんでいたけれど、それが日本でどのように受容されてきたかの話。どのように編纂されてきたかも含めて読み物としてめちゃ面白い。それと、「いかにして〇〇は〇〇したか」構文はアーサー王伝説を編纂した「アーサー王の死」の章タイトルに由来しているということを知れたのは結構なアハ体験。
あと、コラムとして本文の途中に差し込まれている侘助さんという方のコラムが完全にオタク特有の早口文体なんだけど読みやすくて、なんというか筆力を感じてすごい。
#いかアサ ようやく読み始めてるんですがめちゃくちゃ読みやすくて良いし、日本で受容されてきた歴史面白い(夏目漱石が薤露行というアーサー王伝説の創作本を出してたとかぜんぜん知りませんでした) https://t.co/8pKw6SvIbt
— sugamasao (@sugamasao) 2021年1月10日
残念ながらkindle版はないのですが、amazonでも物理本は購入できます。kindle版があればな〜〜と思いつつも、この本は装丁もめちゃくちゃ凝っているので本で購入する方が良い体験を得られると思います。
眼の誕生
進化の過程でどのように生物が眼という器官を発生させたかという話。推理小説のような書きっぷりで、表題に到達するまではそれなりに読み進めなくてはいけないけれど、光と生物の関係についてじっくり説明していくので、それはそれで読み物として面白い。
眼が発生するのは光を検知して外敵を発見するなどする光受容体をより発達させていったものという内容が段階を経て理解できる構成になっていて良かったのと、三葉虫が目を獲得していった話とかは読み応えありました。
これも物理本しかなかった。
ユニコーン企業のひみつ
いわゆるスクラムのような1チームで成果を出す規模を超えてしまったときに、Spotifyはどういうアプローチでスケールさせていったか?ということが書いてある。LeSSのようなスクラムチームをスケールさせる手法をとっている場合、おそらくアプローチは異なるけど目指す方向は似てるはずなので、Spotifyがどういう取り組みをしていたかは解像度を高めるための参考になりそうな気がしています。
詳しくはこっちに書いた。
OKR
OKR、雰囲気でしかわかってなかったので参考になった。とはいえ、エンジニアの評価軸に合わせるの難しいな〜〜とか、今週の目標確認やウィンセッションなどのイベントごともスクラムを取り入れた組織だとコンフリクトしそうだよな〜〜などの感想を得た。杓子定規なOKRとスクラムの併用は難しいだろうなあ(導入するならそれなりに強い意志でアレンジしていかなといけなさそう)というのはググるとチラホラ見かけました。
エラスティックリーダーシップ
以前読んでいたのを再読した。
感想としてはあまり大きく変わらないけれど、当時よりは解像度が高い状態で読めて良かった。
つまみ食いで読んでるシリーズ
手を動かしながら学ぶTypeScript
同僚が執筆したTypeScriptの本。 #手TypeScriptというハッシュタグ流行らせたいんですが、全く流行っていません😭
まだ読み進めている途中ですが、個人的には数年前、当時在籍していた会社でJS -> TSへのコンバートをやったときにこの本があれば……!! という気持ちがあります。
達人プログラマー 第2版
いまさら語ることは無い良本ですが、最近になって読み直したけどやっぱり良いこと書いてありますね。
最初は数々の引っ越しイベントを経て手元に残していた初版を読んでいたのですが、圧があったので2版を買いました(のちに気が付いたんですが、kindle版ではなくどこかのPDF版を購入済みだった)。
なぜ新しいほうを読まないのか
— Kakutani Shintaro (@kakutani) 2021年10月24日
アジャイルな見積もりと計画作り
自社ではスクラムをベースとした開発をしており、「これ、どう考えたら良いんだっけ?」というときに見直しています。
Clean Agile
こっちの本はほぼ読んだと思うけど、アジャイルな見積もりと計画作りと同じく、考え方を参考にしたいときに読み直しています。
エンジニアリング組織論への招待
これはまだ読んでいる途中なのですが、2021年の後半はチーム内のチーフというロールをやることになったので1on1をやる機会もあり、メンタリングについて興味があって読んでいます。 これは1on1をやり始めてすぐ読むべきだったな〜〜〜というくらい良い本でした。まだ読みきれてないけど……。
エンジニアのためのマネジメントキャリアパス
どういう内容かはそのっつさんの感想を読むとわかりやすいですが、ひとまず自分の目の前にあるチームのマネジメント文脈ほしさで5章まで読んだ。
自社のチーフというロールはプレイングマネージャーなので、参考や目標に。
これはkindle版が無いのが惜しい
おわりに
読んだマンガとかも書こうと思ったけど分量がめちゃ多くなりそうなのでここで終わります。
といいつつ、いま一番良いなと思っているのを書いておくと、ハイパーインフレーションです(最初はイロモノ的なマンガかなと思ったけど、完全にシリアスな笑いを狙ってきていて引き込まれる良さがある)。 shonenjumpplus.com
RubyMineでよく使ってる機能
この記事は SmartHR AdventCalendar の2日目です。
20代の頃はVimを使っていたのですが、膝に矢を受けてしまいIDEを使うようになってしまいました。
さて、そんなこんなで普段使いしているRubyMineですが、この中でよく使う機能について少し書いてみようかなと思います。
というわけで書いていきますが、ファイルを開くとか検索するとかはメジャーだと思うのでそれ以外について書いていきます。
コードを見ているときに便利なやつ
キャプチャを取得する際のサンプルとしてrubygems.orgのコードをRubyMineで開いています。
cmd + click
で関数ジャンプをした後、cmd + [
で戻る
メソッドを探索していて、「今見ているメソッドを呼び出していた部分を読みたい」というときに戻れて便利。
さらに、cmd + ]
で戻った状態から進むことができるらしいのですが、何らかのアプリにショートカットが吸われていて使えた試し無し😇
開いているファイルを「Project」タブ内で選択状態にする
読み進めているファイルと同じ階層の別ファイルを開く場合などに、シュッと周辺ファイルを探すことができて便利。
「Structure」で概要を見る
単純にメソッド一覧が表示されるだけでも便利なのですが、RSpecなど、テストを書いているときにどのようなテストケースが書かれているか把握するのに便利(RSpecだと階層構造も把握しないとテストの全体像が把握できなかったりするので)。
RSpecに関しては--dry-runを実行するという手もありますが、編集しながら横に表示できるのが便利なんですよね〜〜〜。
With Coverageでコードカバレッジを見る
テストを実行するときに、「'With Coverage'」を選択するとテスト実行後にカバレッジを表示できます。 網羅率がどうこうというより、テスト対象としたいコードに対して正しくテストが通っているかを確認するのに便利。
便利Plugin
ゴテゴテ入れるのは好きでないので、あまり入れてませんが……。
GitLink
Open in GitHubのショートカットを追加するやつ。カーソルがある行に対応するGitHubのパーマリンクが取得できるので便利。
https://plugins.jetbrains.com/plugin/8183-gitlink
Find Pull Request
該当行を変更したであろうPRを探してくれるくん。システム考古学してるとき便利。
https://plugins.jetbrains.com/plugin/8262-find-pull-request
Railways
rails routeをシュッと見る用です。絞り込みもできるので便利。
SmartHRに入社して1年が経った
めでたいのでハッピーターンをたくさん食べました
妻に隠れてハッピーターン食いまくったのがバレた
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年5月1日
これまでのあらすじ
sugamasao.hatenablog.com sugamasao.hatenablog.com
近況
5/1で入社して1年ということになりました。
10年ちょっとぶりの転職なので世の中のエンジニアリングについていけなかったらどうしようかと思っていたのですが、幸いにもWebアプリケーションエンジニアとしてなんとかやれてます(たぶん……)。
今までロクに経験のなかったチームでの開発ってやつを楽しんでます。
SmartHRとぼく
忘れそうなので書いておきます。
認知のきっかけ
2018年
この頃、転職はまだ少し先の話という認識でいました。
少なくとも半年後に転職するとかそういう気持ちではなく、IT業界にありがちな、そのうち転職するとしたら合いそうな会社の目星をつけておこうくらいの温度感ですね。
- おそらく最初に認知したのはこのconnpassだったと思う
- もしかしたらRubyKaigiでの宮田さんの話だったかもしれないけど、このRubyKaigiは不参加だったのでTwitterのTLごしにうっすら認知していた可能性がありそう(いまとなってはこの時点で認知していた気がするけど、存在しない記憶の可能性がある)
- エンジニア向けの体験入社制度ができましたの時に名前だけじゃなくて事業も把握したはず
- というのも、当時は私自身も半蔵門に勤務していたので、ふつうの出社気分で体験入社できそうだな〜とか考えたりしていたのだった
- 良さそうな会社という認識はあったので転職する気持ちが高まってたらすぐに飛びついていた可能性はあった
2019年
アラフォーで同じ会社に10年いるのやばくね? みたいな気持ちが高まっており、ワンチャン転職しても良いかもっていう気持ちになってきた年です。
正確に書くと、40歳過ぎてから転職するのヤバそう(転職した時の期待値を越えられなさそう)という気持ちが強く、40歳になる前に−−そして転職に失敗した場合の再転職バッファも考えると今のうちに一度転職しておいた方が良さそうだなみたいな事情です(2019年当時、私は37歳)。
- Rails DMのランチセッションでSmartHRが会社紹介をしていて、その話を聞いた時かなり魅力的に感じた記憶がある
- この手のランチセッションって、ご飯食べながらだし、言うても話半分で聞く感じになりがちだと思うのですが、なんかめちゃくちゃ響いたんですよね
- この時点ではすぐに転職活動するつもりはなかったのですが、時が来たら話を聞きにいこうと思った
- この手のランチセッションって、ご飯食べながらだし、言うても話半分で聞く感じになりがちだと思うのですが、なんかめちゃくちゃ響いたんですよね
- そのほかにはたらいの話がすごく良さそうに思えて、人が増えていってもちゃんと対処できてそうという雰囲気を感じたのだった
ちなみに、これが響いた様子です(これはさまざまな感情を圧縮した結果のコメントです)
SmartHRの話、とにかくお金の誘惑があるw
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2019年3月23日
それから
以前の転職活動メモにも少し書きましたが、転職活動は2019/10ころから始めていました。
初手は転職ドラフトで本当に自分自身に市場価値あるんですか……?みたいなところを見つつ、転職ドラフト経由以外に自分からいくつかの企業にコンタクトをとったのが11月末〜12月くらいって感じですね。
SmartHRに関しては、たまたま参加したイベントに人事の方がいらっしゃったのでダイレクトアタックして選考フローに乗せてもらいました(ふつうにHPから応募しようと思っていたので、これは本当に偶然)。
その後、なんやかんやあって、ありがたいことに内定はいくつかいただけたのですが、どの会社も魅力的で本当に迷っており、パーフェクトRuby on Railsの改訂作業を行う精神力が保てなくなったりしました(それはまた別のお話)。
ここまでを振り返ってみると
SmartHR社は転職に対するマインドシェアが高まっている時にちょうどよく認知を高めるイベントがあったのかな〜〜という感じはありますね。
最終的に決断した一手はこれらとは別にありましたが、そこに至るまではやはり「タイミングが合っていた」というのは結構重要なファクターだったかもしれません。
露骨な宣伝
それはそれとして、CTOからのお知らせにあるとおりSmartHRではWebアプリケーションエンジニア(に限らず)積極採用中なので、もし話を聞いてみても良いかなって人がいらっしゃればぜひ以下の資料やエントリーページをみていただければと思います。
会社説明資料はこちら。
以下の採用ページにある各職種の募集ページからエントリーしていただけますが、カジュアル面談のエントリーも可能なので、まずはどんなもんか話を聞いてみようかって場合はそちらを選択していただければと思います。
露骨な宣伝2
パーフェクトRuby on Railsも何卒よろしくお願いします。
🦄ユニコーン企業のひみつを読んだ🦄
私は訳者お二人のファンなので書いました。まあもちろん、それ以外にも単純にスクラムをもうやっていないという宣伝はシンプルに気になりますよねということでシュッと買って読みました。

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方
- 作者:Jonathan Rasmusson
- 発売日: 2021/04/26
- メディア: 単行本(ソフトカバー)
かんたんな感想
スクラムとかアジャイルとかあまり詳しくないので小学生並みの感想です。
今北産業
- 「スクラムをやっていない」isいわゆるSpotifyモデルの話
- ただ、これはあくまで著者がSpotifyに所属していた時期(2014〜2017)のモデルであって、いまどうなっているかを書いているわけではない
- 「Spotifyモデル」is少数チームで迅速に開発をする速度を維持しながらスケールさせるには?という話
- このモデルを実現させるためには"開発チーム"みたいな閉じた座組みではなく、経営陣を含めた考え方、つまり企業の文化を変えなきゃダメだよねということを述べている
ちなみに、本文の補足を書いてある「訳者あとがき」はインターネット上に公開されているので、購入前に一読してみると良いかもしれません。
感想
Spotifyモデルのことを名前しか知らなかったのだけど、どういう思想のもと作られたものかわかってよかった。 また、これは読めばわかることだけど、「スクラムをやっていない」、それはそうだけど事業規模や会社に合わせて変化させていった結果であって、取り組みはスクラムの知見や経験をベースにしていてスクラムは役に立たなかったとかとかそういう話ではなさそう。
Spofityモデルの話をベースにしているけど、どちらかというと"テック企業になるためには文化を作っていかなくてはいけないんだよ"というメッセージが書いてあるように思えたので、形をまねるのではなく自社がより良い一歩を踏み出すための参考にする感じが良いのかなあ。
👇のような話もあるし、世の中銀の弾丸なんてないのじゃ……(真偽のほどはわかりません)。
ちなみに、Spotifyモデルを見ていてLeSS(大規模スクラム)と似ている*1ようで異なるなーと思ったのですが、お互いに影響を与えたりがあったりしていたんですかねえ。
読書メモ
🦄の「エンタープライズ企業」ってのは受託で社内システムを請け負ってる生業のことなんだなあ(1章を読みました)
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年4月30日
🦄3章まで読みました。自分たちのチームが本書の「🦄企業の開発チーム」とどう違うのかを考えながら読んでいました(だいたい似た雰囲気な気がする。少なくとも大きな隔たりは感じない)
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年4月30日
🦄曰くスクワッドが大切 “スクワッドが高パフォーマンスを発揮できるようにサポートし、新たな人材を採用し、雇った優秀なメンバーが辞めずに働き続けてくれるような環境を整えること”
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年5月1日
🦄の4章、トライブについて読みました。スクワッドが良いのは分かったけど、その枠組みを現実世界でどのようにパフォーマンス(やスケール)を高めていくか、そのためにどういったことが必要かなどが書いてあるように理解しました。
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年5月1日
🦄5章を読んだ。ロードマネージャーと一緒に働いてるスクワッド内のPOはどのように協調して働くのだろうか。ロードマネージャーがPOっぽさを感じた(これはたんなる自分の思い込み)けど、そうではないんですよね、きっと。
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年5月2日
🦄6章のこの文章めっちゃいい。腕に彫っておきたい
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年5月2日
”これは「みんな同じチームなんだ」
という意識によるものだ。あなたの問題は私の問題でもある。だから私はあなたを手伝ったほうがいい。”
ここ数週間、ずっとグルグル考えていたことが🦄にズバッと書かれていた。9章、あまりに良すぎたので人類みんな読んで欲しい
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年5月3日
🦄読了。スクラムじゃないなら何をやっているんだ?!みたいな表面的なプラクティスの話ではなかったけど、めちゃくちゃ良かった。たぶん所属している組織、チームによって受け取る段階は異なるだろうけどいわゆるテック企業にお勤めの皆さんは読んだら何かしら発見はあると思う
— sugamasao@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2021年5月3日
*1:どっちも企業文化から変えないと価値をデリバリーできないですよねって話は共通してるかな〜とか
2020年のメモ
振り返るほどかっこいい生き方してないのですが、今年は転職があったり書籍の出版があったりしたので、せっかくなのでメモしておきます。
1月
- 転職活動が佳境に入る
- 具体的に言うと選考が最終選考に入り、いよいよどこに入社するか決断しなくてはいけない
- 改訂版パーフェクトRuby on Railsの執筆新体制でリブート
- @_yasaichi さん、@igaiga555さんを含めた新体制でやっていく気持ちを新たにしたところ
- 執筆自体は2019年の秋頃から進めていたのですが、現体制では目標となる発売日までには手が足りず厳しい状態だったのでした
- サイゼリヤで豪遊して近年稀に見る二日酔いになる
2月
- 転職活動の最終選考が終わり、いよいよどこに入社するか決めなくてはいけない感じになる
- 決められないおじさんだったので、体験入社やエンジニアの方との会食などを開いてもらうものの、新型コロナの影響で予定が伸びたりしていた
- 退職手続きなどを進める
- 今思うと、入社先が決まってないのに退職するの結構スリリングじゃん
- 改訂版パーフェクトRuby on Railsの執筆が佳境に入りつつある
- と言いつつ、転職活動などで精神力を使い果たして身が入らず進捗が厳しい状態に
3月
- 入社先を決定する
- 入社を決定した一方、内定辞退の連絡をする必要もあり、本当によくしてもらったのでつらかったです
- 11年近く在籍した会社を退職した(3月の時点では正確には最終出社で、有給消化期間に突入)
有給フルバースト35連休です。よろしくお願いします。
— 焼きそばパン@改訂版パーフェクトRuby on Rails発売中💎🚃📕 (@sugamasao) 2020年3月27日
4月
- 無を満喫する(と思いきや執筆や登壇準備で全然ゆっくりできなかった
- 日本に緊急事態宣言が発令される
- ホットクックで料理を作ることを覚える
- Railsエンジニア養成読本をネタに銀座Railsで登壇
- https://ginza-rails.connpass.com/event/171333/
- 新型コロナの影響でリスケやZoom開催などいろいろありました
- 改訂版パーフェクトRuby on Railsの執筆が佳境に入る(ガチ)
5月
- 現職へ入社
- 1ヶ月以上働かない状態から突然の仕事で身体がびっくりしちゃうね
- 昨今の諸事情により初手からフルリモート
- 改訂版パーフェクトRuby on Railsの執筆が終盤に入り、レビューや修正などで大忙し
6月
- 改訂版パーフェクトRuby on Railsの執筆が終盤に入り、レビューや修正などで大忙し(2回目)
7月
- 改訂版パーフェクトRuby on Railsが発売しました。良かったですね
- https://kaigionrails.doorkeeper.jp/events/109773 で宣伝させていただきました
8月
- 試用期間が終わり無事に正社員になれました。良かったですね
9月
- RubyKaigi Takeout 2020 感想戦@仮想松本という自社イベントに参加しました
10月
- https://icare.connpass.com/event/189356/ でRubyの歴史について話しました
11月
- かなり難産だったRubyKaigi Takeout 2020 感想戦@仮想松本の参加レポートを書きました
12月
- 憧れのおつかれ🚿に呼んでいただきました
- 特に、2回目冒頭の「海でも川でも溺れたことがある」という紹介はかなり良さみが深かったです
ここまで書いてみて
今年は転職活動をはじめ、人間との関わりが多かった一年でした*1。 その節は大変お世話になりましたが、引き続きどうぞよろしくお願いいたします。
*1:新型コロナの影響がある中、リモートの対応で滞りなくやりとりできてよかった
RuboCopの実行がOOMに殺されて1ヶ月が過ぎました
これはSmartHRアドベントカレンダー2日目のエントリです。
私の所属先であるSmartHRではCircle CIを使ったCI環境を用意していて、その中でRSpecやRuboCopを実行しています。
そんななか、たまにRuboCopのjobがReceived "killed" signal
と発して死んでゆく現象が発生していました。
しかも、なんとなく発生頻度が高まっているような……?という気がしてきて地味に困るので調査を開始しました。死亡現場である動作ログをよく見るとRuboCopの検査自体は終了しているように見えるものの、その後のなんらかの処理で死んでいる*1ように見えました。
RuboCopの実行後の処理とは
CircleCIではJUnit形式で実行結果を出力しておくと違反があったときいい感じにしてくれる機能があるため、例に漏れず我々のプロダクトでもJUnit形式のXMLを出力していました。
(📝 RuboCopでは0.80.0からJUnit用のフォーマッターを内蔵するようになったので、rubocop-junit-formatterなどの専用gemを使わなくても良いようになっています)
処理の流れをエスパーするに、おそらくこの処理で長大なXMLを生成しようとして力尽きているのでは……と予想を立てました。
で、どうしたの
どうしようかなあと困っていたのですが、RuboCopのチェンジログを眺めていると0.85.0*2
で--display-only-failed
というオプションが追加されていることを知りました。これはJUnit形式のXMLを生成する際に利用できるオプションで、失敗したものだけをXMLに出力するという大変省エネなオプションです。
use --display-only-failed
見立て通り死因がOOMであればこのオプションは有効であろうと思われるので、早速このオプションをCircleCIのconfig.ymlに追加しました。
すると、目に見える効果としてRuboCopのジョブ自体の実行時間が結構減りました(具体的には4〜5分だったものが1〜2分で終わるように)。
そして、数日の間CircleCIの結果を眺めていたところ、RuboCopの不審死は見当たらなくなりました。
どうやら問題は解決できたようです。やったね🎉
というわけで
人間は慣れてしまうもので、ちょっと不便だな〜というものはそのままにしがちなのですが、ちゃんと調べたら解決できることもあるので、面倒がらずに調べてみると良いですね。
特にCIの設定は一度設定するとあまり注視しないものなので、効果的な設定があってもそのままにされがちだったりします。たまには設定の棚卸しをすると良いかもしれませんね。
*1:killが送られてきているので、OOMっぽいなと当たりをつけました
*2:https://github.com/rubocop-hq/rubocop/blob/master/CHANGELOG.md#0850-2020-06-01