When was the build passing?

その build passingはいつ?

when was the build passing
when was the build passing

If you use GitHub, you often see Travis CI's badge on README.

GitHubを使っていると、READMEにTravis CIのバッジが張ってあるのをよく見る。

Nice badge: build passing (Travis CI)

build passing(Travis CI), ナイスバッジですね。

However, when the build passing, it is not clear until you see other date parts.

ただ、いつのbuild passingなのかは、他のところを見ないとわからない。

authored on Jul 5, 2013 (captured on Sep 9, 2014)

"a year ago"!!!

I think if the build passed a year ago, then it will pass now, won't it?

一年前build passingだったら今もbuild passingじゃないの?

It is not assured!


I want to solve this! This is the theme of my talk and my motivation to come here.

こういうのをどうにかするぞ! が話したいことで、話しに来たモチベーションです。

This paper is here http://bit.ly/travis-ci-meetup-tachikoma-io

この資料は http://bit.ly/travis-ci-meetup-tachikoma-io です。

sanemat - sanemat {AT} tachikoma.io

Travis CI Meetup 2014-09-17

When was the build failing? Actually 'Now'?

いつ落ちたの? ホントに「今」?

when was the build failing
when was the build failing

When I use Travis CI and GitHub, I meet this kind of story usually. No matter language I use.

Travis CIとGitHubを使っていると、プログラミング言語問わずよくある話だと思う。

I found out the failing test, which is library A's one that I want to use.


I watched the result in Travis CI, and then I understood this.

Travis CI見て、どこが落ちてるかわかったぞ。

I searched this. After that I found out that API requires 'ac' params, this is the problem.


Thus, I fixed failing test!


And finally sent a pull request, but...


many test failed
many test failed

WOOOOOO! Fail, Fail, Fail and Fail!

うわぁぁぁぁ。 Fail, Fail, Fail and Fail!

fail pass
fail pass

This is about the library A's component library dependencies.


We didn't fix the dependency version, this is one of the causes.


It is not a story that, we would have to fix the dependency version.

ただし、依存バージョンを固定してればよかった、という話では ない

This library A depends on another library B, and A hits B's bug.


Hence, We should update B's version.


We can update v0.1.2 to v0.1.3 easily.


Now B's version is v1.2.3, oh. v1 requires bump node.js version.


Bump node.js version break A's another dependency library C,




Great news, The build failing is not happening now !

壊れたのは じゃない

Too many tests fail on now pull request. It is difficult to find out where I should fix.

のpull requestではテストが盛大に落ちる、場所の特定も面倒だ。

If I'm at my first failing build, then I can find out this easily, and fix it easily too.


I'm sick of this!

こういうの、うんざりだ! よくある!

This talk so far is when you use the libraries which other people made.


It is the same thing when you provide the library/application.


First of all, I change the provider side!


I made Tachikoma.io, this is an awesome application.

神webアプリつくった Tachikoma.io

interval pull request
interval pull request

Interval Pull Request

定期的な Pull Request

What are the pros doing that?


Differences between rebuild via Travis CI API

Travis CIのAPIで、rebuildするのとの違い

When start fails, we can visually see logs from Travis CI and GitHub.

いつから落ちたか視覚的にTravis CIとGitHubでわかる。

The best thing is relax version dependencies. semver...


We can see the build log at Travis CI.

Travis CIでビルドログを見るとわかる。

Leave it to Travis CI is that you can Travis CI.

Travis CIのできることはTravis CIに任せる。

Leave it to Tachikoma.io is that you can Tachikoma.io.


You should do what you want to precisely do.


Dependency update is not what you want to do! What you want to do is writing application!

だって依存のアップデートがあなたのやりたいことじゃないでしょう? アプリケーション書きたいでしょ!

We use Travis CI in combination with Tachikoma.io!

Tachikoma.io と組み合わせて使うのは, Travis CI!

This is not a bad app?


One more time.


What Tachikoma.io does.


This sends interval pull request to the repository's master branch with nothing.

リポジトリのmaster branchに対して、何もせずに、定期的に、Pull Requestを送る。

Then you can find diff from the result of pass/fail at Travis CI.

すると、Travis CIのpass/failで差分に気付く。

(Maybe 4minutes?)


You boast your product, Tachikoma.io?

自分のプロダクト Tachikoma.io の自慢?



One more thing...


I said 'This send interval pull request with nothing'. Nothing!

何もせずに、定期的に、Pull Requestを送る、と言いました。

In specific language:


ruby: bundler, perl: carton, node.js: npm, each langualge has its own package manager library.

ruby: bundler, perl: carton, node.js: npm と言語ごとにパッケージマネージャーがある。

Gemfile, Gemfile.lock, cpanfile, cpanfile.snapshot, package.json, etc. There are meta files for control dependencies.

Gemfile, Gemfile.lock, cpanfile, cpanfile.snapshot, package.json, etc. と依存関係コントロールするためのメタファイル群がある。

This is Dependency Hell.

これらは依存関係update hellだ。

This is obvious that the only way to survive is updating them to the latest stable frequently.


Interval bundle update(ruby)/ carton update(perl) / david update(node.js)

定期的に bundle update (ruby) / carton update (perl) / david update (node.js)

strategy: bundler
strategy: carton
strategy: david
strategy: none (default)

Do you do this? I think you don't do, do you? "Yes I do", you says, you can do this more easily.

やってますか? やってないでしょ? やってる? もっと簡単になるよ。

You can do it with Tachikoma.io. The only thing that you should do is putting .tachikoma.yml.


Interval bundle update and send a pull request from Tachikoma.io.

定期的に bundle updateしてTachikoma.ioからpull requestが来る。

In this case, not only Travic CI builds log, but also the GitHub compare view.

この場合、Travis CI のbuildログだけでなく、GitHubのcompare viewも頼りになる。

Leave it to Travis CI is that you can Travis CI.

Travis CIのできることはTravis CIに任せる。

Leave it to Tachikoma.io is that you can Tachikoma.io.


You should do what you want to do.


We use Travis CI in combination with Tachikoma.io!!

Tachikoma.io と組み合わせて使うのは, Travis CI!!



Use Tachikoma.io.

Tachikoma.io 使って。

Free for public repositories.

public repos版はFree!

Subscription for private repositories.

private repos版は月額有料です

More ideas


We use Travis CI in combination with Tachikoma.io!!!

Tachikoma.ioと組み合わせて使うのは, Travis CI!!!

This is service statement below


Not updating the dependent libraries, does not damage the library/application immediately. When adding a new library that you want to use, occurring a security issue in a library which is already in use, it is extremely difficult to find the right version that functions properly with it. Even if you find the right combination, it's very reactionary and it even gets harder when adding the next one. Furthermore, sometimes with an older version, you won't be able to enjoy new library features, increase in speed, updated version of Ruby/Node.js/etc., and other benefits. Ultimately, choosing the latest(stable) combination periodically will keep damages to a minimum. Everyone knows this, so what's stopping them?

I believe it's due to the lack of tools and integrations. That is where Tachikoma.io comes in.

ライブラリの依存バージョンを上げないことは、すぐにはライブラリやアプリケーションにダメージを与えません。 新しく使いたいライブラリを追加するときに、既存のライブラリにセキュリティフィックスが出たときに、それぞれが正しく動作するバージョンの組み合わせを見つけることは、非常に困難です。 仮に組み合わせを見つけたとしても、すごく後ろ向きですし、次を追加するとき、より困難になって立ちはだかります。 また、ライブラリの新機能、スピードアップ、Ruby/Node.js/etc.のバージョンアップなどメリットを享受するために低いバージョンだとそれが使えないことがあります。 結果的に一番痛みが少ないのは、常に定期的に(安定した)最新版を組み合わせていくことです。 ここまでみんな知ってるしわかってるのに、なぜ出来ない?

それはツールやインテグレーションがまだ不足しているからだ、と私は考えます。 それを埋める1つのパーツがTachikoma.ioです。

We ship to the world!



sanemat {AT} tachikoma.io