Saddler - checkstyle to anywhere

restore_bundled_withを使ってBundlerのBUNDLED WITHをうまく取り扱う

2015-06-21T00:00:00+00:00

tl;dr

Bundler v1.10.0からBUNDLED WITHのsectionが導入された。
restore_bundled_withを使うことで、Bundler開発チームの精神を逸脱して(!)、異なるversionのBundlerとBUNDLED WITHをうまく取り扱う。

BUNDLED WITHのsectionで差分が出る

Bundler v1.10 とBUNDLED WITH

Bundler v1.10.0からBUNDLED WITHというsectionにbundle updateを実行したBundlerのversionを記録するようになった。日本語詳細はこちらが詳しい。 Ruby - BUNDLED WITH で Gemfile.lock が更新されてしまう件 - Qiita

挙動の確認

Bundler v1.10.2でbundle updateして、BUNDLED WITHにversionを記録しておく。

$ cat Gemfile.lock
GEM
  remote: https://rubygems.org/
  specs:
    actionmailer (4.1.11)
      actionpack (= 4.1.11)
(snip)
  unicorn-worker-killer
  webmock

BUNDLED WITH
   1.10.2

Bundler v1.9.9で bundle update

BUNDLED WITHのsectionごと消える。悲しい。

$ bundle update
(update)

$ git diff
(snip)
@@ -289,6 +290,3 @@ DEPENDENCIES
   unicorn
   unicorn-worker-killer
   webmock
-
-BUNDLED WITH
-   1.10.2

Bundler v1.10.4(新しい)で bundle update

BUNDLED WITHの記録を更新する。

$ bundle update
(update)

$ git diff
(snip)
@@ -291,4 +292,4 @@ DEPENDENCIES
   webmock

 BUNDLED WITH
-   1.10.2
+   1.10.4

Bundler v1.10.1(古い)で bundle update

Warning出しつつ、BUNDLED WITHは更新しない。

$ bundle update
Warning: the running version of Bundler is older than the version that created the lockfile.
We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.
(snip)

$ git diff
(no diff)

正しい解

まずは、Bundlerのversionをv1.10系の最新版に上げる。そして、依存ライブラリのバージョンを上げていくと同時にBundlerも最新版が出るたびに上げていく。

現実解?

そうは言っても、localではpreとかv2とか新しすぎるものも使いたい。
実際にproductionで実行するBundlerのversionと離れてしまいかねないのはいつか問題になりそう。
Gemfileの中はBundler管轄だけど、Bundler自体はそこで管理してないわけで、lockの記述に引きずられるのはどうなんだろう(私見)
minimalなbundlerのmini_bundler(仮)が薄くいて、bundle execなどのコマンドはその内側でバージョン管理されたbundlerで実行すればいい?(私見)

などの理由から、Bundler開発チームの精神を逸脱して(!)、restore_bundled_withというgemのrestore-bundled-withコマンドを使う。

restore_bundled_with

Gemfile.lockのBUNDLED WITHにリポジトリとdiffがある状態で、restore-bundled-withコマンドを実行する。つまり、bundle updateしたあと、commitする前に、restore-bundled-withする。すると、リポジトリからBUNDLED WITHのsectionを取り出してきて、そこだけ元に戻る。

Bundler v1.9なら、消えたsectionが戻る。より新しいBundler v1.10なら、使った記録がそこだけ戻る。

Example

Newer Bundler Case

$ cat Gemfile.lock
(snip)
  unicorn-worker-killer
  webmock

BUNDLED WITH
   1.10.2

Execute bundle update by Bundler v1.10.3.

$ bundle update
(update)

$ git diff
(snip)
@@ -291,4 +296,4 @@ DEPENDENCIES
   webmock

 BUNDLED WITH
-   1.10.2
+   1.10.3

Then, execute restore-bundled-with.

$ restore-bundled-with
(restore BUNDLED WITH section)

$ git diff
(no diff)

There is no diff, because this restores BUNDLED WITH from git repository.

まとめ

Bundler開発チームの精神を逸脱するので、あまり推奨はしない。最新版を使って、もし壊れていたらみんなで直していくのが、アプリケーションを健全に保つ一番痛みが少ない方法なのです!

詰まったら聞いてください。このサイトやREADMEなどに反映します。 ruby-restore_bundled_withにスターください!

参照

restore_bundled_withを使ってBundlerのBUNDLED WITHをうまく取り扱う was originally published by Kenichi 'Sanemat' Murahashi at Saddler - checkstyle to anywhere on June 21, 2015.

Ruby version policy with Travis-CI

2015-03-28T00:00:00+00:00

Ruby uses semver after 2.1.0.

# .travis.yml
- 1.9.2
- 1.9.3
- 2.0.0
- 2.1
- 2.2

So this means 1.9.2-p330(latest), 1.9.3-p551(latest), 2.0.0-p643(latest), 2.1.5(latest), 2.2.1(latest). But 2.1.0 means exactly 2.1.0.

They follows Travis-CI’s latest precompiled one.

Ruby version policy with Travis-CI was originally published by Kenichi 'Sanemat' Murahashi at Saddler - checkstyle to anywhere on March 28, 2015.

TravisCIとCircleCIでちょっとずつ違うビルド環境の考え方の違い

2015-03-17T00:00:00+00:00

tl;dr

TravisCIとCircleCIの根底にある違いの考え方を理解すると早い。
そして、違いを考慮しているproductを使うと便利。
- e.g. checkstyle形式の結果をpull request review commentするsaddler

CI result

考え方

CircleCI

pushされたbranchをビルドする。

TravisCI

pushされたbranchをビルドする。
pull requestのbranchを、仮にmasterにmergeしてみて、ビルドする。

仮にmasterにmergeしてみて??

TravisCIの二つ目のがわかりにくくて、混乱する。やっていることは正しいんだけど、挙動が直感から外れるので、 TravisCIヘビーに使っているユーザーにもわりと意味不明挙動扱いされやすい(要出典)

pull requestするとtravisのビルドがなぜか2個走る
(GitHub statusが最新結果しか取れなかった頃は)一度passしたはずのテストが、なぜかあとからやってきたfailにかき消される passしたはずのテストはどこへ
.travis.yml でよく見る branches: only: - master ってなんだよおれはmaster以外のテストもしたいぞあれ、よくわからないが意図通りに動いてるぞ何だこの設定

たとえばbranchを作った時のmasterと今のmasterが乖離していて、 pull requestのbranchのテストは全部通るけど、mergeしたらmasterが落ちる、というのはよくあることだと思う。そこを人間任せにするのか「ちゃんとmasterに追い付かせておいてね」、仮にmergeしてみてtestするのか、は考え方による。後者は便利に見えるが、なんで落ちたかよくわからない状況になることもありがち。

branchのpushでbuildされるとジャマ

となると単にbranchをpushしただけでbuildされるとジャマなので、

# .travis.yml
branches:
  only:
  - master

としたい。これで、master branchへの変更、およびmasterに対してのpull requestに仮にmergeしてみて、が走る。大きめのfeatureブランチを作っていて、そのfeatureブランチに対するpull requestも仮にmergeしてみて、をしたい場合

# .travis.yml
branches:
  only:
  - master
  - feature/your-big-change

とすればよい。

なにかこのブランチが作られた時には、hookで何かしたい、などの場合は

# .travis.yml
branches:
  only:
  - master
  - /^cron_for_tachikoma\/.*/

とする。正規表現が使える。

pull request時の挙動

TravisCI

pull request作成時にhookで起動する。条件を満たしていれば。

pull request済みのbranchに追加のcommitでも起動する。

CircleCI

pull request作成時にはhookで起動しない。 branchのpushを検知する側だけなので。

だから、pull requestに対して何かをしたい、例えばlintしてコメントをつけるとか、の場合、さっさとpull requestをつくらないと、コメントをpostする先のpull requestがない状態で、処理が終わってしまう。 branchをpushしてしばらくしてからpull request作成、そのpull requestに追加でcommitしてpush、この後者のpushのタイミングで初めてコメントが付くことになる。ちょっと注意。

git操作での挙動

TravisCI

仮にmergeしてみる TravisCI式がいいことづくめか? というとそうでもない。

# TravisCI checkoutの挙動(logより)
$ git clone --depth=50 git://github.com/sanemat/ruby-example-rails-banana.git sanemat/ruby-example-rails-banana
$ cd sanemat/ruby-example-rails-banana
$ git fetch origin +refs/pull/2/merge:
$ git checkout -qf FETCH_HEAD

$ tig
13fac8f 2015-03-16 23:35 Murahashi Sanemat Kenichi M─┐ [HEAD] Merge c47af08fe6c62f6c95fa9dea440866d6348ac38
c47af08 2015-03-16 23:35 sanemat                   │ o Bundle update 20150316_23-34-12
37f6de7 2015-03-17 08:07 Murahashi Sanemat Kenichi o─┘ [master] {origin/HEAD} {origin/master} chore(tachiko
8b7d629 2015-03-17 07:58 Murahashi Sanemat Kenichi o chore(travis): add debug

$ git branch
* (detached from FETCH_HEAD)
  master

git 操作でなにかするアプリの場合、あまりこれを想定した挙動になっていないことが多い。それからたとえば、GitHubのapiと連携してpull requestにreview commentをつけたいので、上のtigで言うc47af08を取りたい場合に、うってなる。 saddler-reporter-support-gitでは結構頑張って解決している。 feature branchにmasterをmergeして追い付かせた時に正しく検出しなそう、とかある。

注) TravisCIに限れば、環境変数 TRAVIS_COMMITで該当コミットが取れる。

この「仮にmergeしてみる」は色々流派がありそうで、実際対TravisCIでは動いているけど、他のパターンが有るときに全部解決してるかは自信ない。

pushされたbranchのビルド

Travisは必要最低限にチューンしてあるので、masterとかorigin/masterとかいない。ちょっとだけ注意。

git checkout -b YOU_WANT_TO_CREATE origin/master

と手癖で打つとorigin/master無いので落ちる。

# TravisCI checkoutの挙動(logより)
$ git clone --depth=50 --branch=cron_for_tachikoma/56e24ecc-46bd-4d15-92fb-8d27fde41c8c git://github.com/sanemat/ruby-example-rails-banana.git sanemat/ruby-example-rails-banana
$ cd sanemat/ruby-example-rails-banana
$ git checkout -qf 8b7d6291495e947c7961e98dd9d89042eed2fd05

$ git branch
* (detached from 8b7d629)
  cron_for_tachikoma/56e24ecc-46bd-4d15-92fb-8d27fde41c8c

$ git branch -r
  origin/cron_for_tachikoma/56e24ecc-46bd-4d15-92fb-8d27fde41c8c

余談

checkout -b したいときは

git checkout -b YOU_WANT_TO_CREATE "${TRAVIS_BRANCH}"

か単に

git checkout -b YOU_WANT_TO_CREATE

とする。

CircleCI

CircleCIはおそらく事故防止のためにgit関連のログをwebからは表示しないので、推測だけど

# CircleCI checkoutの挙動(推測)
$ git clone git://github.com/sanemat/ruby-example-rails-banana.git ruby-example-rails-banana
$ cd ruby-example-rails-banana
$ git checkout YOUR_TARGET_BRANCH

してるだけだと思う。オーソドックス。そして多分cloneは初回だけで、cacheしつつあとはfetchとcheckoutっぽい。 sshで入るとこんな感じなので。

$ git branch
  chore/use-tachikoma
  cron_for_github/530f0756-3664-4631-b5f4-eb53a842677a
* cron_for_tachikoma/bar-boo
  master
  pull/9
  tachikoma/update-20150222035312
  tachikoma/update-20150301035325

remote側も綺麗に全部見える(必要最低限ではなく富豪的)

$ git branch -r
  origin/HEAD -> origin/master
  origin/chore/use-tachikoma
  origin/cron_for_github/0e560ce0-6ae0-49b4-a8f9-26b335a752b1
  origin/cron_for_github/44f3c4e7-af74-4e29-bbbf-6c04e1b41048
  origin/cron_for_github/530f0756-3664-4631-b5f4-eb53a842677a
  origin/cron_for_github/5b9d9688-3844-42a4-b34a-3d519177e7b3
  origin/cron_for_github/foo-bar-baz
  origin/cron_for_tachikoma/148fbb23-dc21-461b-b207-5be874ea864f
  origin/cron_for_tachikoma/2212ad06-cdd2-4e77-8071-8552f1268d9e
  origin/cron_for_tachikoma/6344f6a9-2989-4352-9e5e-78ca1f71cc41
  origin/cron_for_tachikoma/bar-boo
  origin/master
  origin/pull/9
  origin/tachikoma/update-20150215035300
  origin/tachikoma/update-20150222035312
  origin/tachikoma/update-20150301035325
  origin/tachikoma/update-20150307_13-26-17
  origin/tachikoma/update-20150307_13-34-52
  origin/tachikoma/update-20150308_15-01-02
  origin/tachikoma/update-20150315035345
  origin/tachikoma/update-20150315_15-03-42

余談

これたまに git fetch origin --prune しないと膨れ上がりそう。ログとかの都合上あったほうがいいのかもだから詳しくは調べてない。

まとめ

普通にやったらこうなる、を高速に解決しているのがCircleCI。多分Jenkinsで自分でやったらこうなりそう、ただし低速。ちゃんとやったらこうなる、を正しく解決しているのがTravisCI。ただし、正しく理解しないと、適当に、じゃあこうかな? とやっても正解にたどり着けない。

drone.io, wercker, teamcity, codeship, あたりのメジャーどころは、だいたいどっちかなんじゃないかな(未調査)、カバーできてるんじゃないかな、カバーできてるといいなあ。詳しい人に補足おねがいしたい!!

ローカルやCI上で動くはずのツールが、CIサービス上では動かないとき、このへんの詰めが漏れてることが多いので e.g. pronto なぜか動かないときは、ココらへんに気を配ってcontributeするとよいです。なお、 checkstyle形式の結果をpull request review commentするsaddler などのpacksaddleプロダクトはその辺のCI間の差異を吸収して、使うときは考えなくていいように、作ってます。

参照

TravisCIとCircleCIでちょっとずつ違うビルド環境の考え方の違い was originally published by Kenichi 'Sanemat' Murahashi at Saddler - checkstyle to anywhere on March 17, 2015.

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

2015-03-07T00:00:00+00:00

tl;dr

Cron for GitHubで定期的にCIサーバーのフックを起動する
CI側では、特定のブランチの場合のみ起動するスクリプトを用意する
自分のやりたい操作をして、git_httpsable-push, pull_request_create でPull Requestを送る

定期的にDependency UpdateのPull Requestを送る

フックの起動

Cron for GitHubのschedulerはこのように設定した。

bundle exec cron-for-github clear --slug=metarubygems/carrion_crow --namespace=cron_for_tachikoma --verbose && bundle exec cron-for-github ping --slug=metarubygems/carrion_crow --namespace=cron_for_tachikoma --verbose

Cron for GitHubの使い方はリンク先を参照する。

GitHubとHerokuの組み合わせでCron for GitHub – Saddler - checkstyle to anywhere

キモはnamespaceの指定で、cron_for_tachikoma/XXXXXというブランチを定期的に作るようにする。 CI側ではこのブランチを監視する。

CI側スクリプト (CircleCI)

CI側では、テスト後にスクリプトを実行。なお、例はCircleCIの場合。

test:
  post:
    - bin/run-tachikoma.sh

実行するスクリプト。特定のブランチを監視して、あとは曜日で起動するしないの頻度を決めている。この場合、日曜のみ起動。環境変数 GITHUB_ACCESS_TOKENにtoken を入れている。

#!/usr/bin/env bash
set -ev

# only sunday
if [[ "${CIRCLE_BRANCH}" != "master" && "${CIRCLE_BRANCH}" =~ ^cron_for_tachikoma/.* && $(date +%w) -eq 0 ]]; then
  # gem prepare
  gem install --no-document git_httpsable-push pull_request-create

  # git prepare
  git config user.name sanemat
  git config user.email foo@example.com
  HEAD_DATE=$(date +%Y%m%d_%H-%M-%S)
  HEAD="tachikoma/update-${HEAD_DATE}"

  # checkout
  git checkout -b "${HEAD}" origin/master

  # bundle install
  bundle --no-deployment --without nothing --jobs 4

  # bundle update
  bundle update

  git add Gemfile.lock
  git commit -m "Bundle update ${HEAD_DATE}"

  # git push via https
  git httpsable-push origin "${HEAD}"

  # pull request
  pull-request-create
fi

exit 0

Git HTTPSable Pushや PullRequest Create はリンク先を参照する。

以上により、定期的にライブラリの依存関係をアップデートしてPull Request 出来るようになった。

TravisCIの場合

(Edited: 2015-03-17 15:15)

pull request以外はmasterのbuildしか対象にしていない場合、.travis.ymlでcron_for_tachikomaも監視する。

branches:
  only:
  - master
  - /^cron_for_tachikoma\/.*/

if pull request以外のところを変更する。 TravisCIのgit checkoutの方式によりorigin/masterが居ないので、git checkout -b "${HEAD}" "${TRAVIS_BRANCH}"にする。もしくはgit checkout -b "${HEAD}"にする。

#!/usr/bin/env bash
set -ev

# only sunday
if [[ -n "${TRAVIS_PULL_REQUEST}" && "${TRAVIS_PULL_REQUEST}" == "false" && "${TRAVIS_BRANCH}" =~ ^cron_for_tachikoma/.* && $(date +%w) -eq 0 ]]; then
  # gem prepare
  gem install --no-document git_httpsable-push pull_request-create

  # git prepare
  git config user.name sanemat
  git config user.email foo@example.com
  HEAD_DATE=$(date +%Y%m%d_%H-%M-%S)
  HEAD="tachikoma/update-${HEAD_DATE}"

  # checkout (for TravisCI)
  git checkout -b "${HEAD}" "${TRAVIS_BRANCH}"

  # bundle install
  bundle --no-deployment --without nothing --jobs 4

  # bundle update
  bundle update

  git add Gemfile.lock
  git commit -m "Bundle update ${HEAD_DATE}"

  # git push
  git httpsable-push origin "${HEAD}"

  # pull request
  pull-request-create
fi

exit 0

備考

反対に、webhook ping用のブランチである cron_for_tachikoma/XXXXX ではテストをスキップする、というのを入れておかないと、テストのキューが多く詰まるような環境では悪い影響出る可能性があるので注意。

他言語でも

実行するスクリプトの中身はシェルスクリプトでコマンドが並んでいるだけなので、もちろん言語非依存。 composer updateでもpod updateでもOK。どんなコマンドオプションだとCIサーバー上で動かしやすいのかは、 Tachikoma gem 見るといけそう。

まとめ

ライブラリを組み合わせて、CIサーバーから依存関係アップデートしたPull Requestを定期的に送る事ができるようになった

使ってみたをブログやqiitaに書いてもらえると助かる！フィードバックください！！他にも使い道がありそう。

参照

定期的にライブラリの依存関係をアップデートしてPull Requestする was originally published by Kenichi 'Sanemat' Murahashi at Saddler - checkstyle to anywhere on March 07, 2015.

Httpsで簡単に、ログ安全に、git pushする Git HTTPSable Push

2015-03-06T00:00:00+00:00

tl;dr

Git HTTPSable Pushを使うことで、Httpsで簡単に、ログ安全に、git pushする。

git-httpsable-pushの実行結果イメージ

使い道

TravisCIや、CircleCIからGitHubにPushしたい
Git HTTPSable Push を使いgit httpsable-push で簡単に、ログ安全に、httpsでのgit pushが出来る

ログ安全とは?

$ git push --quiet "https://${GITHUB_ACCESS_TOKEN}@github.com/<repos_name>.git" gh-pages 2> /dev/null

と書けば、TravisCIやCircleCIから安全にpushできる。でも、--quietや2> /dev/nullのオプションを書き忘れるまたは書き損じると、tokenがログの中に漏れてしまう。いちいち書くの大変。さらに、TravisCIやCircleCIはどうしてもログ経由のデバッグになるので、ログが全く出せなくなると苦しい。

使い方

gem install git_httpsable-push
git httpsable-push origin YOUR_BRANCH

gitリポジトリの設定から、https://${GITHUB_ACCESS_TOKEN}@github.com/<repos_name>.git をコマンド内部でいい感じに作る。このため、リポジトリがgit://...でもgit@...でも、GITHUB_ACCESS_TOKEN以外の設定は不要。たとえば、git httpsable-push origin gh-pagesと書けばOK。

$ git config --get remote.origin.url
git@github.com:packsaddle/ruby-git_httpsable-push.git
# GITHUB_ACCESS_TOKEN=__MY_TOKEN__

# success
$ git httpsable-push origin refactor/logger-to-class --verbose
I, [2015-03-06T19:29:54.250481 #33391]  INFO -- GitHttpsable::Push: Starting Git
I, [2015-03-06T19:29:54.270408 #33391]  INFO -- GitHttpsable::Push: git '--git-dir=/Users/sane/work/ruby-study/git_httpsable-push/.git' '--work-tree=/Users/sane/work/ruby-study/git_httpsable-push' config '--list'  2>&1
I, [2015-03-06T19:29:54.281424 #33391]  INFO -- GitHttpsable::Push: git '--git-dir=/Users/sane/work/ruby-study/git_httpsable-push/.git' '--work-tree=/Users/sane/work/ruby-study/git_httpsable-push' config '--list'  2>&1
I, [2015-03-06T19:29:56.632766 #33391]  INFO -- GitHttpsable::Push: git '--git-dir=/Users/sane/work/ruby-study/git_httpsable-push/.git' '--work-tree=/Users/sane/work/ruby-study/git_httpsable-push' push 'https://MASKED@github.com/packsaddle/ruby-git_httpsable-push.git' 'refactor/logger-to-class'  2>&1
I, [2015-03-06T19:29:56.632944 #33391]  INFO -- GitHttpsable::Push: {:output=>nil}

# error occurs
$ git httpsable-push origin refactor/logger-to-class --verbose
I, [2015-03-06T19:33:47.692967 #34984]  INFO -- GitHttpsable::Push: Starting Git
I, [2015-03-06T19:33:47.701617 #34984]  INFO -- GitHttpsable::Push: git '--git-dir=/Users/sane/work/ruby-study/git_httpsable-push/.git' '--work-tree=/Users/sane/work/ruby-study/git_httpsable-push' config '--list'  2>&1
I, [2015-03-06T19:33:47.711167 #34984]  INFO -- GitHttpsable::Push: git '--git-dir=/Users/sane/work/ruby-study/git_httpsable-push/.git' '--work-tree=/Users/sane/work/ruby-study/git_httpsable-push' config '--list'  2>&1
I, [2015-03-06T19:33:50.657268 #34984]  INFO -- GitHttpsable::Push: git '--git-dir=/Users/sane/work/ruby-study/git_httpsable-push/.git' '--work-tree=/Users/sane/work/ruby-study/git_httpsable-push' push 'https://MASKED@github.com/packsaddle/ruby-git_httpsable-push.git' 'refactor/logger-to-class'  2>&1
E, [2015-03-06T19:33:50.657632 #34984] ERROR -- GitHttpsable::Push: Have a question? Please ask us:
E, [2015-03-06T19:33:50.657667 #34984] ERROR -- GitHttpsable::Push: https://github.com/packsaddle/ruby-git_httpsable-push/issues/new
E, [2015-03-06T19:33:50.657711 #34984] ERROR -- GitHttpsable::Push: options:
E, [2015-03-06T19:33:50.657778 #34984] ERROR -- GitHttpsable::Push: {"debug"=>false, "verbose"=>true, "force"=>false, "tags"=>false}
/Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/git-1.2.9.1/lib/git/lib.rb:917:in `command': (Git::GitExecuteError) git '--git-dir=/Users/sane/work/ruby-study/git_httpsable-push/.git' '--work-tree=/Users/sane/work/ruby-study/git_httpsable-push' push 'https://MASKED@github.com/packsaddle/ruby-git_httpsable-push.git' 'refactor/logger-to-class'  2>&1:remote: Invalid username or password. (GitHttpsable::Push::GitHttpsablePushError)
fatal: Authentication failed for 'https://MASKED@github.com/packsaddle/ruby-git_httpsable-push.git/'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/git-1.2.9.1/lib/git/lib.rb:727:in `push'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/git-1.2.9.1/lib/git/base.rb:329:in `push'
        from /Users/sane/work/ruby-study/git_httpsable-push/lib/git_httpsable/push/repository.rb:24:in `push'
        from /Users/sane/work/ruby-study/git_httpsable-push/lib/git_httpsable/push/cli.rb:29:in `push'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
        from /Users/sane/work/ruby-study/git_httpsable-push/lib/git_httpsable/push/cli.rb:59:in `method_missing'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/command.rb:29:in `run'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/command.rb:126:in `run'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
        from /Users/sane/work/ruby-study/git_httpsable-push/vendor/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
        from exe/git-httpsable-push:5:in `<main>'

ログとエラーの中の該当部分をマスクしている(MASKED部分)ので、ログに出ても安全。エラーが出てもエラーを見ながら直せる。安心して使える。

まとめ

Httpsで簡単に、ログ安全に、git push出来る。HTTPSable Push。

使ってみたをブログやqiitaに書いてもらえると助かる！フィードバックください！！ masterにmergeしたらgh-pagesに自動でpush、が典型的に使える例。そのほか、bundle updateしてgit pushしてpull requestなど、TravisCI, CircleCIで何か処理をしたい時に便利。

詰まったら聞いてください。このサイトやREADMEなどに反映します。 ruby-git_httpsable-pushにスターください!

参照

Httpsで簡単に、ログ安全に、git pushする Git HTTPSable Push was originally published by Kenichi 'Sanemat' Murahashi at Saddler - checkstyle to anywhere on March 06, 2015.

GitHubとHerokuの組み合わせでCron for GitHub

2015-03-03T00:00:00+00:00

tl;dr

GitHubとHeroku Schedulerの組み合わせでCron for GitHubを実現する

cron-for-githubの実行結果イメージ

使い道

たとえば、毎日ping/ のbranchを生成しておく。
CI用のスクリプトには、ping/ 以下のbranchのビルドだったらこれこれする、と条件を書く。
完成!

はじめ方

cron_for_github-app のからherokuにデプロイ。
cronを使いたいリポジトリがprivateならrepo, publicならpublic_repoのgithub access tokenを発行。
GITHUB_ACCESS_TOKEN にそれを設定。
このコマンドを実行できるようになる。

cron-for-github ping --slug=YOU/YOUR_REPO

Heroku Schedulerで定期実行。

heroku schedulerの設定イメージ

コマンドのオプション詳細は cron_for_github gemのreadme参照。

オススメ設定

このままだと、いっぱいブランチが作られていくママなので、

bundle exec cron-for-github clear --slug=YOU/YOUR_REPO --verbose && bundle exec cron-for-github ping --slug=YOU/YOUR_REPO --verbose

こんな感じに実行して、pingする前にclearするとよい。 verboseオプションつけるとそれなりにログが出る。そして、それをnewrelicやlogentriesなど、ふつうのherokuアプリのように監視する。

demo

CircleCI
- Branches packsaddle/example-circle_ci-pull_request

CircleCIで確認してます。 10分おきに起動したらたくさんbranchできたので、今は1日1回起動中。 TravisCIでも動くはず。

.travis.ymlで

branches:
  only:
    - master

している場合は

branches:
  only:
    - master
    - /^cron_for_github\/.*$/

など、自分の設定に合わせて要修正。

まとめ

GitHubとHeroku Schedulerの組み合わせでCron for GitHubを実現する

使ってみたをブログやqiitaに書いてもらえると助かる！フィードバックください！！多分他にも使いみちがありそう。詰まったら聞いてください。このサイトやREADMEなどに反映します。 ruby-cron_for_github-appと ruby-cron_for_githubにスターください!

参照

GitHubとHerokuの組み合わせでCron for GitHub was originally published by Kenichi 'Sanemat' Murahashi at Saddler - checkstyle to anywhere on March 03, 2015.

CI環境からGitHubのPull Requestのstatusを簡単に通知するコマンド

2015-02-28T00:00:00+00:00

tl;dr

github_status_notifierコマンドでCI環境からGitHubのPull Requestのstatusを簡単に通知する。
TravisCIがやってるみたいなテスト中は黄色、テスト終わったら緑/赤のを簡単に作れる。

github-status-notifierの実行結果イメージ

使い方

単体で使ってもよし、典型的には、他のコマンドの前後を state pendingと exit-status $?で囲んで使う。こうするとこのスクリプトが始まったところでpending の黄色が始まり、成功/失敗で success/failureのstatusが表示できる。

gem install github_status_notifier

github-status-notifier notify --state pending --context saddler/rubocop

SOME_YOUR_COMMAND

github-status-notifier notify --exit-status $? --context saddler/rubocop

使い道

GitHub関連サービス作るような人には便利に使えそう。Saddlerとの連携などに便利。

チェックがまだ始まってないのか、チェック中なのか、チェックが終わって何も問題がないから無言なのか、途中で終わってるのか、 Pull Requestの画面上から把握できるようになる。

これから用にJenkinsなりで自前CIを作ってて、status通知連携だけで来てない人(いるのか?)は多少便利になるかも。でもその場合はこっち見てその通りに作るほうがよい。 Building a CI server | GitHub API

ruby-github_status_notifierにスターください!

参照

CI環境からGitHubのPull Requestのstatusを簡単に通知するコマンド was originally published by Kenichi 'Sanemat' Murahashi at Saddler - checkstyle to anywhere on February 28, 2015.

変更したファイルにrubocopやjscsを実行して pull requestに自動でコメントする

2015-02-27T00:00:00+00:00

tl;dr

変更したファイルにrubocopやjscsを実行して、pull requestに自動でコメントさせる方法。
コマンドをパイプでつないで、CIからsaddlerコマンドで書き込みする。
デモリポジトリに rubocop, travis ci, jscs, travis ci エラーになるpull requestしてみてね!

saddlerの実行結果イメージ

一番目がjscs, 二番目がrubocop。

流れ

diffのあるファイル名を取り出す

$ git diff --name-only origin/master
README.md
bin/run-tests.sh
lib/example/travis_ci.rb

こんなdiffにrubocop や jscsを実行したい。 diffのあるファイル名を取り出す。

lint実行したいファイルだけに絞り込む

$ git diff --name-only origin/master \
 | xargs rubocop-select
/Users/sane/work/tmp/packsaddle/example-ruby-travis-ci/lib/example/travis_ci.rb

lint実行したいファイルだけに絞り込む。 rubocopはrubocop-select という対象絞り込みのコマンドを使う。

ちなみに、jscsの場合はgrepにした。ここ以外は一緒なので割愛。

$ git diff --name-only origin/master \
 | grep -e '.js$'
/Users/sane/work/tmp/packsaddle/example-ruby-travis-ci/lib/example/some_your.js

lint実行して結果をcheckstyle formatで出力する

$ git diff -z --name-only origin/master \
  | xargs -0 rubocop-select \
  | xargs rubocop \
      --require rubocop/formatter/checkstyle_formatter \
      --format RuboCop::Formatter::CheckstyleFormatter
<?xml version='1.0'?>
<checkstyle>
  <file name='/Users/sane/work/tmp/packsaddle/example-ruby-travis-ci/lib/example/travis_ci.rb'>
    <error line='7' column='120' severity='info' message='Line is too long. [163/120]' source='com.puppycrawl.tools.checkstyle.Metrics/LineLength'/>
  </file>
  <file name='/Users/sane/work/tmp/packsaddle/example-ruby-travis-ci/lib/example/travis_ci.rb'>
    <error line='16' column='120' severity='info' message='Line is too long. [163/120]' source='com.puppycrawl.tools.checkstyle.Metrics/LineLength'/>
  </file>
</checkstyle>

実行して、結果をcheckstyle formatで出力。 rubocopの場合はcheckstyle formatterをgemで入れる。 jscsの場合はcheckstyle reporterがある。exampleで用意したものはgulp-jscsなので、中から無理やり。 npm runでxargs渡せるんだろうか。

$ git diff --name-only origin/master \
  | grep -e '\.js$' \
  | xargs ./node_modules/gulp-jscs/node_modules/.bin/jscs \
      --reporter checkstyle

このステップは、checkstyle formatでどうしても出力できなかったら、そのライブラリのreporterを書くか、結果のconverterを書く。

checkstyle formatの中から、増えた行のエラーだけ抽出する

$ git diff -z --name-only origin/master \
  | xargs -0 rubocop-select \
  | xargs rubocop \
      --require rubocop/formatter/checkstyle_formatter \
      --format RuboCop::Formatter::CheckstyleFormatter \
  | checkstyle_filter-git diff origin/master
<?xml version='1.0'?>
<checkstyle>
  <file name='/Users/sane/work/tmp/packsaddle/example-ruby-travis-ci/lib/example/travis_ci.rb'>
    <error column='120' line='7' message='Line is too long. [163/120]' severity='info' source='com.puppycrawl.tools.checkstyle.Metrics/LineLength'/>

  </file>
</checkstyle>

checkstyle formatのなかから、増えた行のエラーだけ抽出する。この場合7行目はdiffにあったけど、16行目はdiffに無かったのですね。

増えた行のエラーをPull requestにコメントする

$ git diff -z --name-only origin/master \
  | xargs -0 rubocop-select \
  | xargs rubocop \
      --require rubocop/formatter/checkstyle_formatter \
      --format RuboCop::Formatter::CheckstyleFormatter \
  | checkstyle_filter-git diff origin/master \
  | saddler report \
     --require saddler/reporter/github \
     --reporter Saddler::Reporter::Github::PullRequestReviewComment

増えた行のエラーをPull requestにコメントする。おめでとうございます!

demo

TravisCI
- rubocop, 実際に実行するスクリプト
- jscs, 実際に実行するスクリプト
CircleCI
- rubocop, 実際に実行するスクリプト
- jscs, 実際に実行するスクリプト

TravisCIとCircleCIで確認してます。 CircleCIのほうは、外部リポジトリからのPull Requestでbuildしないようにしているので、 TravisCIのリポジトリで、rubocop/jscsが指摘する項目があるプルリクエストを出して試してみてください! 自分のリポジトリに設定する場合、GitHub Tokenの設定が必要です。各デモのREADMEとスクリプトを参考に設定してください。

まとめ

変更したファイルにrubocopやjscsを実行して、pull requestに自動でコメントさせる方法。
コマンドをパイプでつないで、CIからsaddlerコマンドで書き込みする。
デモリポジトリに rubocop, travis ci, jscs, travis ci エラーになるpull requestしてみてね!

使ってみたをブログやqiitaに書いてもらえると助かる！フィードバックください！！詰まったら聞いてください。このサイトやREADMEなどに反映します。 gitlabで使いたい！stashで、bitbucketで、etcなどもこれから作りやすいようにしてます。reporterの作り方書きます。コマンドラインツールなんでも行けるはずなので他にもeslintなど行ける！！ ruby-saddlerにスターください!

変更したファイルにrubocopやjscsを実行して pull requestに自動でコメントする was originally published by Kenichi 'Sanemat' Murahashi at Saddler - checkstyle to anywhere on February 27, 2015.