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のビル
定期的にライブラリの依存関係をアップデートしてPull Requestする
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_c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
