TravisCIとCircleCIでちょっとずつ違うビルド環境の考え方の違い
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のビル
変更したファイルにrubocopやjscsを実行して pull requestに自動でコメントする
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 -
CircleCIをpublic reposに使うときに気をつけること
CircleCIをpublic reposに使うときに気をつけること TL;DR CircleCIをpublic reposに使うときは、気をつけて使う必要がある。秘匿情報を入れてる時は、fork reposからのpull requestをbuildしてはいけない(CircleCIデフォルト設定)。 経緯 CircleCIでfork reposからのpull requestが来ない。 Tachikoma.io を使ってみた – えいのうにっき circle ciでpublicで同じように使えてる、気がしてたけどprivateとは条件がよく考えると違ったり、travis-ciと全く同じようにはいかない、部分があった。 で、普通に考えるとcircleci的には危ない機能なので設定は安全に倒してあった。 注意 悪意のあるpull requestがたとえばrake testに puts YOUR_
CircleCI で docker + serverspecを実行する - moock’s blog
前回はローカルで docker 上で serverspecを実行した。 今回は、CircleCI上で dockerを起動し、knife-soloで構築し、 serverspecでテストができるようにしようと思う。 全体のワークフローとしては、以下の順序となる。 Githubにchefのコードをpushする CircleCI上でdockerを起動する dockerのimageを作成し、コンテナを起動。 そのコンテナに対し、knife-soloを実行し、インフラを構築。 構築したコンテナに対して、serverspecを実行し、テストを行う そうすると、Githubの Merge Pull Request ボタンにテストの結果が表示される。 CircleCIの始め方などは、割愛。 Dockerfileを使用して、dockerイメージを作成する まず、以下のDockerfileを作成し、ssh可能
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
