Travis CI で常に Node.js 最新 LTS と最新安定版を使う - Qiita
GitHub のリポジトリで CI するときは Travis CI のお世話になってるんですが，Node.js ではひとつ問題がありました． 現在 Node.js では 4.6.0 が LTS で 6.7.0 が最新安定版です．なので，.travis.yml には次のように書いていました． ですが，これだと LTS や最新安定版のメジャーバージョンが上がった時に .travis.yml もメンテする必要があります．リポジトリがたくさんあると修正して回らないといけなくて面倒で，もっと雑に放っておいても良い感じにやってほしい．ということで，「最新安定版」および「最新の LTS」を指定する方法を調べてみました． 結論としては下記のようにバージョンを .travis.yml に書いておけば良いようです．
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のビル
Travis CIでipaを作るときのCode Signが失敗するのを修正したメモ - 24/7 twenty-four seven
一週間ほど前から（おそらくTravis CIの環境がXcode 5.1に変わってから）Travis CI上でipaファイルの作成に失敗するようになってしまって、TestFlightにベータ版を自動的にアップロードすることができなくなっていたのを昨日ようやく直したのでメモ。 ↓ということで以前に書いた記事はちょっと古くなってしまいました。 本文はそのままですが、参照先のgistの内容はアップデートしてあります。 ユビレジのiPadアプリのCI環境をJenkinsからTravis CIに移行したときのまとめ - 24/7 twenty-four seven 失敗している箇所のエラーメッセージは下記の通り。ipaを作る前の、プロジェクトのビルドでコード署名をするところで失敗しているけど、これだけだと原因がよくわからないのでまず手元で同様のメッセージが出る状況を再現することを実行しました。 
Travis CIでxcprettyを使ってxcodebuildのログをきれいにする - Qiita
背景 xcodebuildを使ってビルドを行うと整理されていない不要なビルドログがたくさん出てしまうので、Travis CIを使ってテストを日常的に行っていたとしてもいざテストが落ちた場合にどこが問題あるのかがすぐに見つけられずイライラする事が多いと思います。 xcprettyとは xcprettyを使うとxcodebuildが出力するビルドログをきれいに整理して色つきで出力できるようになります。利用方法もxcodebuildの結果をパイプで受け取るだけなので非常に簡単です。 ログの出力形式をrspec風にしたりJUnitレポート形式のxml出力等もできるようです。 xcprettyをTravis CIに導入する xcprettyを導入するとTravis CIにおいても以下のようにログがきれいに整理され色付きで出力することが出来ました。画像の通りログの見た目・わかりやすさの違いは歴然です。
thedoritos.net
thedoritos.net 2018 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
テストが通った時だけ`npm publish`する - Qiita
npm prepublishは、npm install時に実行してしまいます。 この記事では、それを回避する方法と、TravisCIで利用する方法を紹介します。 方法は、.travis.ymlのafter_successと、package.jsonのscriptsをうまく連携させます。 まず、下記のnpm scriptsを書きます。 { "scripts": { "prepublish": "node -e \"if(process.env.TRAVIS_PASSED){}else{process.exit(1)}\" && npm run compile || echo skip prepublish" } }
[iOS 8] 15分で作れる CI 環境構築 | DevelopersIO
iOSアプリにも継続的インテグレーション環境を こんにちは！今日からMacDownでブログを書いています。荒川です。 モダンなWeb開発では馴染み深くなってきた、CI（継続的インテグレーション）環境を iOS 開発でも弊社では積極的に取り入れています。社内での共有も兼ねて、今回は簡単にまとめます。 「継続的インテグレーション」と聞くととても難しそうで、設定も大変そうです。ですので、最低限コピペで作れる程度の環境構築方法を紹介します。 iOS 開発での CI とは何かを詳しく知りたい方は、弊社諏訪の記事 iOSアプリ開発でCI／継続的デリバリ環境を始めるための4種の神器 を参考にしてください。 今回構築する環境は、以下に該当する方に最適です。 gitを使って iOS 開発を行っている。 チーム内でチャットツールを使っていて、そのAPIが公開されている。 テストコードを書いている。または、その
![[iOS 8] 15分で作れる CI 環境構築 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/b77d33dc9028edad7cf9c2e97b877fb489d569fc/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F11%2Ftravis.png)
Travis CI + Coverall + Node.js (Hubot) で継続的インテグレーションしてみる :: by and for engineers
Nov 12, 2014 Hubot スクリプトのために、CI 環境を整えてみた。説明用にコードを切り出したりしているので、全体の設定は今回使っている libinc/hubot-scripts を見てください。 継続的インテグレーション (Continuous Integration) ツールGitHubTravis CIテスト実行には mocha を利用Coverallsカバレッジ測定には blanket を利用David.テストコードテスト実行には chaimochahubot-mock-adapterを利用しています。Hubot スクリプトは CoffeeScript で書いているので、mocha の設定 test/mocha.opts は以下の様に定義してます。 テストコードは綺麗に整理できていないので、詳細については割愛。 Travis CIオープンソースで良く利用されている。公
いまどきの.travis.yml - teppeis blog
いまさら感もあるのだけど、あまり知られていないようなのでTravis CIの高速化+αなtipsを書いておく。 先にNode.js向けの完成形の.travis.ymlはこちら。 language: node_js node_js: - "0.12" - "4" - "6" sudo: false cache: directories: - node_modules Tipsは3つ。 テスト対象のNode.jsバージョンを指定する sudo: false: コンテナベースの環境を使う cache: 依存パッケージをキャッシュする テスト対象のNode.js/io.jsのバージョンを指定する 最近はカジュアルにio.jsを使う人/プロジェクトが増えてきている（要出典）ので、特に政治的な理由でもなければnpmパッケージのテストはNode.jsとio.jsの両方で流しておくのが良いと思う。.tra
橋本商会 » テストがあるとプルリクしやすい
印象としてそんな感じがする。 だいたいプルリクする時って、バグを見つけて直すのはすぐできるんだけど、自分の修正が何か別のところで副作用を起こしているかもしれない、という不安があってグダグダ色々検証したり他の部分のコードも一応読んだりする時間の方が長いと思う。 そういう時にとりあえずテスト通っていれば、テスト書いたリポジトリ主がokしているような気になってくるから、すぐプルリク出せる。 なるべくrake testとかnpm testとかコマンド一発実行すればテストが走るようにしておいてくれるとプルリクしやすくてうれしい。 プルリク受け入れる側も、Travis CIとかでプルリク自体にテスト通過しましたバッジがついていると安心感がある。 テストの書き方色々ある 去年からnode.js使い始めて、色々作ってるんだけどテストの書き方色々ある気がするのでメモしておく。 具体的な書き方は各リポジトリの
TravisCI、SauceLabs、Protractorで始める簡単E2Eテスト入門 | チャットワーククリエーターズブログ
自転車通勤始めました。@kyo_agoです。この記事はE2EテストAdventCalendar -26日目です。 今日はGithub上でTravisCI、SauceLabs、Protractorを使って簡単に始められる継続的E2Eテストの方法を紹介したいと思います。 ゴールはGithubにPRする毎にTravisCIがProtractorを使ってSauceLabs上で検証した結果を教えてくれるところです。 登場するユーザ名（kyo-ago）、リポジトリ名（Protractor-SauceLabs-TravisCI-sample）は実際のものに置き換えて読んでください。 SauceLabsの登録まず最初にSauceLabsのアカウントを作成します。 この時点ではGithubのリポジトリも何らかの設定ファイルも必要ありません。 「Getting Started」を押してください。 ダイアログが
Middleman で作った web サイトを Travis + GitHub pages でお手軽に運用する - tricknotesのぼうけんのしょ
先日 Middleman を使って sapporojs.org をリニューアルしました。 その際に得られた Middleman での web サイト運用の知見をご紹介します。 Middleman って?? 簡単に説明すると、静的 web サイトジェネレータです。 Jekyll をご存知の方であれば、似たようなものをイメージしていただけるとよさそうです。 Middleman の方が優れている点は、 Asset Pipeline や Template Helpers などの便利な機能を利用をすることができることです。 http://middlemanapp.com/ 逆に Jekyll の方が有利な点としては、 GitHub pages が使えるためデプロイが楽であるという点があります。 そこで今回は、 Jekyll と同じく Middleman を GitHub pages に簡単にデプロイ
Travis CIを使ったGitHubプロジェクトの継続的インテグレーション | 1000ch.net
継続的にテストをする 今更感が否めないのですが、簡単にまとめました。 Travis CIとはなんぞやという方はこちら。 継続的インテグレーションとはなんぞやという方はこちら。 例えばテストの自動化をして、リファクタリングのしやすい環境を作って、 コードの品質向上を継続的に行っていくサイクル。というイメージ。 今回はGitHubとTravis CIで自動化を測りますが、 Jenkinsでビルド環境を整えて、継続的にデプロイをしていくのもひとつです。 テスト周りの環境とか オレオレライブラリにCI環境整えました。一応。 mochaのBDDでテストケースを書いて、イベントのバインド周りのテストはsinon#spy()を。 testemでそのテストをPhantomJSで実行させるといった流れ。 PhantomJS testem mocha sinon mochaのサンプルは公式
ブログをJekyllからmiddlemanに移行してTravis CIでGitHub Pagesにデプロイするようにした - Webtech Walker
ちょうど一年くらい前にWordPressからJekyllに移行したんだけど、今回middlemanで作りなおしてみた。 hokaccha/webtech-walker - GitHub 特にJekyllに不満があったわけでもなく単に技術的興味によるもの。 middleman Middleman: Hand-crafted frontend development middlemanはほぼJekyllのようなものなんだけど、Asset Pipelineが使えたり、テンプレートがerbとかhaml、Slimなどで書けたり、helperが充実してたりする。 RailsのViewまわりの機能をそのまま持ってきたような感じなので、普段Rails使ってる人にとってはJekyllよりも使いやすいかもしれない。個人的にもJekyllよりはmiddlemanのほうが好みだった。 調べた時にでてくる情報量など
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TravisCIでiOSアプリのipaファイルを作って実機に配信する時に便利だったもの | 秋山ブログ