Tachikoma v5.0 (のようなもの)をリリースした

Tachikoma v5.0 のようなツール群のリリースが完了した。

定期的にライブラリの依存関係をアップデートしてPull Requestする – Saddler – checkstyle to anywhere

“v5.0のような”というのは、実際には発展的解消でTachikoma(というオールインワンの解決策)が不要になった。

Releases · sanemat/tachikoma
v2.0(on Jun 23, 2013)からスタートして、ほぼ一発ネタだったわりによく頑張ってくれた。

最近やりたいこと Dependency Update

7割の amatsuda bot, hsbt botを作りたい。
みんな、もっと本当にやるべきことがあるはずだ。
本人はそれはそれで楽しんでいるのかもしれないから(特に面識はないから知らない そのうち聞いてみたい)いいんだけど、なんだかなーってなってしまう。rubyやrailsの特にコーナーケースを直すのはぼくには荷が重いから、そこでてこが効いてるのかもしれない。

Bundle Updateは楽しい。最新の変更についていくのが容易になる。簡単にコーナーケースでバグが踏める。勉強になる。でも、みんなが同じようにgithub探しに行って、diff見て〜というのをやるべきだとは思わない。
作りたいものを作って欲しー
Bundle update楽しい人が、楽しめる場を作ったら、もっとほかのみんなが楽しく出来るんじゃなかろうか。
現時点で表に出ている策以外はまだ影も形もないので、作って解決するものは作る。そうじゃないいろいろを考えたり試行錯誤する時間を作る。

クックパッドでamatsuda, eagletmt がrails, rubyのアップデートをやっているそうだ。

Rails 4 へのアップグレード時に遭遇した問題 – クックパッド開発者ブログ
GMOペパボではhsbt。From ‘Legacy’ to ‘Edge’ 2014 edition // Speaker Deck
GitHubではtmm1。RubyKaigi 2014 | Ruby 2.1 in Production
http://bit.ly/ruby21-in-production

うーむ。一家に一台ほしい。

Dependency Update関連
Tachikoma.ioはその二本目の策です。一本目はTachikoma gem。二本目にして食っていけるかもしれん、と思ったけどそれは甘かったみたい。

最近思っていることはこんな。

strategy: noneはいきなりpull request閉じていいのでは? Tachikoma.io

pull requestひたすら閉じるのツライ

strategy: noneの場合に、いちいち全部閉じていくのはダルい
確かに

strategy: bundlerの場合に、failの上にコミット積み上げてpassしてmergeはある。
(tachikoma.ioにwrite権限出しておく必要はある。)
strategy: noneのfailの上にコミット積み上げてpassしてからmergeすることあるか?
ない
noneなら一律pull request送るやいなや閉じていいのでは?
自前でtravis-ci互換持つのが一番ヨイが、それまでは時間がかかるので…

Release tachikoma v4.2.1: Strategies with cocoapods and composer

tl;dr

Tachikoma v4.2.1 gets the power against objective-c applications and php applications. Those strategies are cocoapods and composer. You can update library dependencies more easily, you’ll be happy 🙂

Tachikoma v4.2.1 はobjective-cのアプリケーションやphpのアプリケーションに対して使えるようになりました。cocoapodscomposerというストラテジー追加のおかげです。依存ライブラリのアップデートがより簡単になるので、幸せになれるでしょう 🙂

Key features

bundle exec rake tachikoma:run_cocoapods is for objective-c application. You receive interval pull request with pods update.
bundle exec rake tachikoma:run_composer is for php application. You receive interval pull request with composer update.
Deprecate bundle exec rake tachikoma:run_bundle, Use bundle exec rake tachikoma:run_bundler instead. This keeps symmetry between other strategies’ name.

bundle exec rake tachikoma:run_cocoapods はobjective-c アプリケーションのための機能です。あなたは定期的にpods updateしたpull requestを受け取ることが出来ます。
bundle exec rake tachikoma:run_composer はphp アプリケーションのための機能です。あなたは定期的にcomposer updateしたpull requestを受け取ることが出来ます。
bundle exec rake tachikoma:run_bundleは廃止予定です。替わりにbundle exec rake tachikoma:run_bundlerを使ってください。これは他のストラテジーの名前との対称性のためです。

Enjoy programming!

プログラミングを楽しみましょう!

Travis CI Meetup 9/17 and Tachikoma.io talk

The meetup about Travis CI will be held on Sep. 17(wed), 2014, at Shibuya Hikarie.
Travis CI Meetup – connpass

I’ll have 5 minutes talk about Tachikoma.io, which is Tachikoma as a service.
My talk title is “When was the build passing? – A gap between Travis CI and GitHub”.
If you have 5 minutes talk, you can attend(At the current time, 2014-09-08 0:02).
Welcome~

Travis CI Meetup が 9/17(水)に渋谷ヒカリエであります。
Travis CI Meetup – connpass
5分のライトニングトークでTachikoma.io (Tachikoma as a service) について話します。
トークタイトルは「その build passingはいつ? – Travis CI とGitHubの間」です。
もう参加募集人数超えちゃってますが、LT話すならまだ一枠空いてます(2014-09-08 0:02時点)。
来てね〜

Release tachikoma v4.2.0: Strategies with david and none

tl;dr

Tachikoma v4.2.0 gets the power against Node.js application and any other applications. Those strategies are david and none. You can update library dependencies more easily, you’ll be happy 🙂

Tachikoma v4.2.0 はNode.jsのアプリケーションやその他様々な言語のアプリケーションに対して使えるようになりました。davidnoneというストラテジー追加のおかげです。依存ライブラリのアップデートがより簡単になるので、幸せになれるでしょう 🙂

Key features

bundle exec rake tachikoma:run_david is for node.js application. You receive interval pull request with david update.
bundle exec rake tachikoma:run_none is the more awesome, this fits various languages. If any application you have on github, you receive interval pull request without change, so you can easily check when test fail.

bundle exec rake tachikoma:run_david はnode.js アプリケーションのための機能です。あなたは定期的にdavid updateしたpull requestを受け取ることが出来ます。
bundle exec rake tachikoma:run_none はもっとすごい機能で、これは様々な言語に適応します。どんなgithub上のアプリケーションでも、あなたは変更なしのpull requestを定期的に受け取ることが出来ます。これで、あなたはいつからテストが落ちるようになったか、簡単にわかるようになります。

One more thing

If you think this is still tedious, it is good news, “Tachikoma as a service” is now private alpha! Keep your eyes open!
まだメンドイと思ってる? それならいいお知らせがあります。”Tachikoma as a service” を今private alphaで作っています。お楽しみに!

Jenkins scheduled build Triggers with environment variable

Jenkinsのbuild periodically(cronもどき)ごとに異なる環境変数渡したい場合、jobを2つ作ると意図通りに出来た。

先行のjobは、cronと Post build action – Trigger parameterized build on other が仕事。Parameterized Trigger Plugin をつかう。後続のjobは渡された環境変数を使うだけ。同時build数や同時起動数の制御もしておけば同時起動不可なbuild複数でも順番にやってくれる。

という説明をtachikoma用に書いた。

https://github.com/sanemat/tachikoma/wiki/Manage-multiple-projects-with-jenkins

kick-tachikoma

This job has only 2 roles, Build periodically (perhaps daily) and Post build action – Trigger parameterized build on other projects. UsingParameterized Trigger Plugin, then kick following tachikoma(s).

tachikoma

Given TOKEN and BUILD_FOR, then tachikoma(s) works!

see: http://stackoverflow.com/questions/18086508/jenkins-scheduled-build-triggers-with-environment-variable

tachikomaにpull requestが来てmergeもしてもらった

tachikomaにpull requestもらったので、ふーむなるほどーって思って、見るだけ見たけど取り込む余裕まではなくて置いておいたら、より良い解決策や別解が提示されて、更によくなってmergeされてた。あとから:+1:って書くだけでいい(書きたくなった)ってすごい。これがsocial codingでopinionatedなproductのちからか!! まあそんなことはなくて、willnetとkyanny ありがとう。これははやめにsanemat/tachikoma から tachikoma/tachikoma に移そう & バージョニングポリシー話し合ったらgemのpush権限も渡してSPOF無くしたい!

Add ‘private’ to type