2週間ぶりの定期リリース。今回のリリースでは、-j をつけたときにビルドジョブを make jobserver という仕組みで賢く振り分けたり、Fable 5 にやらせたメモリ削減を入れたり、cooldown や plugin の渋いバグを直したりとまあまあなボリュームを入れている。
https://blog.rubygems.org/2026/06/24/4.0.15-released.html
ついでに、コンフリクトをいい感じに直すのを claude に仕込みつつあるので、rb_sys のバージョン更新など、今までならコンフリクト解消だる、でやめていたのをウリャっと進めてしまった。
https://github.com/ruby/rubygems/pull/9640
あと、メンテナンスブランチへ auto pick するにはコードベースが違いすぎるので、個別に pull req を用意してマージしたやつが changelog に出てこなかったり、手元の branch が remote origin と差があるときに pick の対象とならなかったり、みたいなケースも claude に「直して」とバンバンぶん投げて直してもらった。
で、RubyGems のリリースは自動化スクリプトによる auto pick を駆使しているんだけど、2-3回は素振りをしてコンフリクトの傾向を把握してから、本番リリース、としていて素振りで修正したコンフリクトが2-3回目の試行では自動で直っていてなんで?と思ったらこれは git rerere という機能だった。
名前だけは知っていたけど、何かはよくわかっておらず、おすすめ設定として有効にしていたので適用されていた、ということっぽい。これは、コンフリクトの修正を間違えてやった場合もそのまま間違えたまま適用、を繰り返すのでだるい、となったので claude に「なんで間違えた修正が繰り返し入るんですか?」と聞いたら、rerere や、forgot を使って消すことができます、というのも教えてくれて勉強になった。
claude を使うとき、あまり丁寧に背景とか説明しないで、やりたいことだけをすごい雑に聞く、というのに慣れてきた気がする。
rubygems では 10 年くらいに渡って、トップディレクトリに bundler というディレクトリを入れたままリポジトリはモノレポだけど、ただコードが同じ箇所にあるだけ、CI には便利、一緒に直すときも便利、という物理的にしか意味がなく、コードの共有化、とか結合レベルの上げ下げ、みたいなことは何もできない状態が続いていたのだけど、AI パワーでやっと lib の下にフラットに配置してしまった。
https://github.com/ruby/rubygems/pull/9634
とはいえ、これをベースに重複している vendor コードの共通化、モンキーパッチしているコードの共通化、なども含めた大きめの計画を丸2日くらいかけて、日本語であーでもない、こーでもない、というのを考えてから「で、これ作れるんですか?」「作れます」まで行けたので進めたのだった。
https://github.com/ruby/rubygems/issues/9236#issuecomment-4748470107
実際にやってみると、手元だけでは実行できないケースで CI が落ちたものの、ひたすら claude に直させたら割とあっさり終わったので 4.0.15 のリリース後にさくっとマージしてしまった。
なんか、bundler 側に lib/rubygems/* というコードを放り込んで、ロード時に二重ロードしない、というガードを入れたら、このまままずはランタイムベースの統合を進めて行ける気がしてきたなあ。頑張ろう。
何でも claude で解決だ、と DataDog にも log drain があるのを知ったので最近よくログをダウンロードしては調査をさせていた git.ruby-lang.org の apache2 のログを DataDog に放り込むようにした。もちろん claude が全部やった。
https://github.com/ruby/git.ruby-lang.org/pull/108
実際にはこれを適用するだけで、claude から DataDog MCP を経由してサーバーの状況を把握できるようになったので捗りまくる。ec2 で面倒見てる奴はこれを入れて回れば claude だけで何もかもをシュッとできるかなあ。
先週の木曜に依頼した修理がダメで改めてメーカーに修理を依頼して、その作業が今日あった。
担当者の作業としてははいはい、って感じで特にでかい作業になることなくサクッと終わって、今までのはなんだったんだ、というくらいレバーが簡単に動くようになった。これ、自分でメンテできるんですか?と聞いたら、カルキが固まるケースなのでできない、また硬くなったら交換して欲しい、みたいな話になっていて「は?」という顔をしてしまった。
電気工事士、みたいな奴ならともかく、自分で買った家につけるものに業者の縛りを入れるのと、自分でメンテできる手段を提供しない、さらに経年劣化は避けられない、ってのは欠陥なんじゃねーの、と思うけど、担当者にブチ切れてもしょうがないので「そうなんですね」という感じで終わり。
うちの台所の水道もこんな感じのメーカー独特のやつで、交換とかメンテができないんだけど、こういうのは家を建てたり、買ったりしてから初めて気がつくポイントだよなあって思った。本当に酷い。
tDiary でも使っている CGI だけど、特に escape 周りとかドキュメントで修正が溜まっていたので新しいバージョンをリリースしておいた。
https://github.com/ruby/cgi/releases/tag/v0.5.2
Ruby 4.0 と fcgi でも軽快に動いているので、必要な人は引き続きご利用ください。
ruby/ruby のリポジトリでは、CloudBees の Smart Tests (旧 Launchable) を使っていて、テスト結果の記録をしつつ flaky なテストのスコアとか、落ちたテスト名などが Web から確認できる。
で、DataDog の MCP を使い始めた流れでふと datadog にも似たようなテスト結果を記録して MCP で呼び出して何かをする、ということができるということを知って、Smart Tests でもなんかできないんすか、というのを onomax さんに聞いたら CLI があります、というのを教えてもらったので試してみた。
https://github.com/cloudbees-oss/smart-tests-cli
で...ドキュメントなどはあまりないので、何でも雑に claude の方針で、「CLI 読み込んでどう使うか教えて」、からの必要な環境変数を渡して「つながるか確かめて」「API 呼べる?」くらいまでやってからより具体的に「ここ1週間で落ちる頻度が上がったテストを教えて」と投げたら、しばらくあーだこーだしてからテスト名を2-3つ出せるようになった。
で、そこから「このテストが落ち始めたコミットを特定して」と投げたら、このコミットです、と自分のコミットを出してきた時には笑ってしまったけど、CLI を使えるようにしたところから、こう API を呼び出します、というところまで大体学習したので次回以降はもう少しスムーズに行けそう。
https://github.com/cloudbees-oss/agent-skills/pull/2
に、手元にあるメモリは skill として使って下さい、と投げておいたので今後はもう少し便利になるかもしれません。こういうの、調べ方はこうした方がもっと効率がいいです、とか工夫した方がいいんだけど、外から見る限りはこれが限界...。
つい最近、Ruby のメーリングリストがサービスのポリシー変更で無条件参加ができなくなってしまい、参加登録するたびに管理者である僕か shugo さんがぽちぽち承認することになってしまった。
で、サービス側に何とかならないのか、と聞いたら、無条件参加にしてもいいけど spam 配信とかあったらすぐに ML 止めるとよ、と割と厳しい返事が来て困ったなあとなっていたので claude cowork で何とかしてみた。
何とか、と言っても cowork の仕組みをざっくり把握してから、Gmail に承認依頼のメール(実際には from とか文面とかを細かく指定)が来たら claude for chrome を入れているブラウザで承認画面を開く、これを 9:00 に実行する、というやつを組んでから軽く試して動いたのでよし!って感じ。
これ、手元では自動化かつスケジュール組めていいんだけど、じゃあ shugo さんに渡せるのか、というと個人アカウントだとなかなかむずいっぽい。こういう自動化は別に、って感じだけど自分だけが楽になってもしょうがないからなあ。引き続き調べていきます。