CircleCI で Android アプリをビルドする時のTIPS - Qiita
general: artifacts: - ./app/build/outputs/apk/ machine: java: version: oraclejdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux test: override: - echo "Nothing to do here" post: - ./gradlew compileDevelopReleaseSources deployment: upload: branch: [master] commands: - ./gradlew assembleDevelopRelease - ./gradlew uploadDeployGateDevelop - ./gradlew assembleProductRelease - ./gradlew upload
Travis-CIでSwift libraryをテストする - Qiita
Travis CIがこのほどXcode 6をサポートしました。 The Travis CI Blog: Status update on the Xcode 6 and iOS 8 rollout Xcode 6をサポートしたということは、Swiftもサポートしたということです。これでようやくOSSなSwift libraryをCIできるようになりました。めでたい さっそくSwiftライブラリをCIしてみましたが、ハマりどころが沢山ありましたので共有します。以下のプロジェクトで実際にCIでunit testを実行しているのでご覧ください。 https://github.com/gfx/Swift-JsonSerializer Travis CIの設定のポイント ポイントは以下のとおり。 test schemeをsharedにする Xcodeのscheme managerでtest用のsch
SML#のプロジェクトをWerckerでCIする - Qiita
SML#で書かれたプロジェクトをWerkecrでCIできるようにする方法を書きます。 前提 対象のプロジェクトがGithub/Bitbucketにあること(プライベートレポジトリ可)。 make check等で単体テストが走るようになっていること。単体テストを書く際はSMLUnitがオオススメです。(というか他に選択肢がない) 設定方法 Werckerの設定 Werckerのアカウント取得やプロジェクトの作成等が必要ですが、そのあたりについてはGithubのプライベートリポジトリでも無料で使えるCI、Werckerを使ってrails newからHerokuのデプロイまでやってみるの「Werckerを設定する」が分かりやすいです。 wercker.ymlの作成 SML#インストール済のOS(werckerではboxと呼ばれる)はすでにmzp/smlsharp-boxとして用意してありあす。
【TravisCI】travis.ymlに書くあれこれ - Qiita
TravisCIのビルドの流れを知ろう！ 1. Githubから(.travis.ymlが配置されている)リポジトリをgit cloneする git cloneの際に、オプション--depth=50が付いています 2. cloneしたリポジトリに移動する 3. git checkoutしてコミットしたコードを取得する .travis.ymlに書いた環境変数はここで適用される 4. キャッシュを使う場合、キャッシュを取得する 5. 使用するRubyのバージョンを指定する 6. before_installで定義したものが実行される キャッシュを使う場合、ここで追加される 7. installで定義したものが実行される 8. before_scriptで定義したものが実行される 9. scriptで定義したものが実行される exitコードが0ならば成功、それ以外は失敗と判定される 10. af
Travis CIとxcprettyを併用すると正しくレポートされないときの対処 - Qiita
CIのホスティングサービス。自分でjenkins管理するのは辛いけどきちんとテストしたい！といったときに使う。 githubのプルリクエストとかにそのブランチの最新のテスト結果を表示してくれる。 実行したいコマンドは.travis.ymlというyamlファイルをgitリポジトリのルートに配置する。 例えば上記のxcprettyを使ったコマンドの場合 上記のように記述します。 xcprettyとTravis CIを併用する このTravis CIとxcprettyを併用すると、レポート結果がうまく出力されないことがあります。 具体的にはテスト自体はこけているのにtravisからはsuccessとしてレポートされてしまいます。 この点についてはこちらの記事 http://qiita.com/radioboo/items/bb3bba734a68f0c25c81 やxcprettyのgithub
Travis Ci上でReact.jsのプロジェクトをPhantomJSでテストした場合にFailする現象 - Qiita
React.jsを使用しているSinatraプロジェクトでPoltergeistを使用したテストを実施した場合に、 自環境では成功するのに Travis CI上で失敗するという事象に出会いました。 Travis上でのエラーログ Capybara::Poltergeist::JavascriptError: One or more errors were raised in the Javascript code on the page. If you don't care about these errors, you can ignore them by setting js_errors: false in your Poltergeist configuration (see documentation for details). TypeError: 'undefined' is
Emacs LispをTravis CIしてみる勉強ノート - Qiita
何の因果か最近Emacs Lispを書くことになりました。 Emacsみたいなこわいエディタの話をしているのは必然的にこわいひとが多いです。 ドラクエで例えるとキラーマシンみたいな方ばっかです。 そんな中、ひのきのぼう/たびびとのふく/Lv1 でぷるぷるしながら調べたこと試したことをまとめて公開します。 新たな勇者のぼうけんの、最初の一歩を手伝えれば幸いです。 注意 Emacs Lispは初心者、それ以外は今回はじめて触ったという体たらくで書いた記事です。 というか、主にこのページの劣化焼き直しです。 Emacs Lispのテスト、依存性管理、CI - 備忘録 この記事を読む方は先にこちらのページをひと通り読みましょう。不自由なく理解できた方は以下を読む必要はありません。 ERTとは ERT is an Emacs Lisp library for regression/unit test
Electron アプリを Travis CI でテストする - Qiita
npm test は node で JS のコードを実行するように package.json で設定し，そのスクリプトの中でテスト用の小さな Electron アプリを実行するようにします． var electron = require('electron-prebuilt'); // ... var finished = child_process.spawnSync( electron, ['path/to/test-app', 'test-file1.js', 'test-file2.js'], {stdio: 'inherit'} ); process.exit(finished.status); テストは Electron アプリ上で実行するため，Electron アプリの stdio を引き継ぐようにします．実行する Electron アプリはエントリポイントとなっている JS
PostgreSQLを使ったRailsアプリケーションをwerckerでbuildしてたらlibruby.soでLoadErrorが出た。 - Qiita
box: wercker/ubuntu12.04-ruby2.0.0 services: - wercker/postgresql build: steps: - bundle-install - rails-database-yml: service: postgresql - script: name: echo ruby information code: | echo "ruby version $(ruby --version) running" echo "from location $(which ruby)" echo -p "gem list: $(gem list)" - script: name: Set up db code: bundle exec rake db:schema:load RAILS_ENV=test - script: name: rspec c
Travis-CIでgit cloneしたautoconfを使う - Qiita
背景 Travis-CIに入っているImageMagickがどうも自分が期待していた APIが使えないビルドであった為、これを自前でビルドしようとしたら、 今度はautoconfが古いと怒られた。 autoconfも自前のモノを入れることにした。 ちなみに、この方法は、古いtravis-ci用のファイルの書き方なので、 新しい書き方で書ける人はそうしたほうが負債にならないと思われる。 autoconfをgitでcloneしてビルドする GNUのツールなので、./configure一発と思いきや、gitで持ってくると まず、configureがない。 このconfigureを作るのに大変苦労した。 autoconfコマンドを１回叩いて、エラーをくらい、めげずにもう一度叩くと、configureを生成してくれるが、travis-ciだと、コマンドの終了コードが0以外だと即エラーで中断なので、困
werckerからslackにビルド結果のnotificationを送る - Qiita
一応ここに全部書いてある Slack Notifications! slackのtoken取得 トークンの取得はIncoming WebHooksから行う https://各ドメイン.slack.com/services/new/incoming-webhookから nortification送りたいチャンネルを選択し Add Incoming WebHooksをクリック トークンが作成されるのでコピー サイドバーのTOKENと書いてある箇所にtokenが表示されてるのでコピー werckerのtoken設定 ApplicationのPipelineにtokenをペーストする ENVIRONMENT VARIABLEに適当な名前を付ける ENVIRONMENT VARIABLEで付けた名前はwercker.yml内で変数として使用できる textのvalueにコピーしたtokenをペースト
Travis-CIでImageMagickをclangでビルドして使うには - Qiita
sudo make install make install-am make[1]: Entering directory `/home/travis/build/kjunichi/ImageMagick' make[2]: Entering directory `/home/travis/build/kjunichi/ImageMagick' /bin/mkdir -p '/usr/lib' /bin/bash ./libtool --mode=install /usr/bin/install -c magick/libMagickCore-6.Q16.la wand/libMagickWand-6.Q16.la Magick++/lib/libMagick++-6.Q16.la '/usr/lib' libtool: install: /usr/bin/install -c magic
Travis CIでxcodebuildを使用する - Qiita
はじめに Travis CIでObjective-Cプロジェクトをビルドする場合、デフォルトでxctoolが実行されるが（Building an Objective-C Project）、xctool自体の問題でエラーになることがある。 このため、xctoolではなくxcodebuildを使用する設定ファイル（.travis.yml）を紹介する。 ビルドのカスタマイズ Travis CIのビルドは2つのステップで構成される： install: 必要な依存物をインストール script: ビルドスクリプトを実行 インストールステップ、スクリプトステップに加え、インストールステップの前、スクリプトステップの前後でカスタムコマンドを実行することができる。詳細はCustomizing the Buildを参照のこと。 設定ファイル（.travis.yml）のサンプル language: objec
CircleCI で GitHubのブランチ更新をフックしてAWS ECSへデプロイする - Qiita
この文書について 対象読者: サーバサイドエンジニア AWS の ECSへのデプロイ を GitHub と CircleCI を使って実施する方法を紹介します 具体的には インフラ構成 (GitHub,CircleCI,AWS にそれぞれどんなデータがあるのか) デプロイはどのような流れで行われるのか デプロイフローの構築 AWS側で準備すること ビルド用にソースコードリポジトリに準備しておくこと CircleCI側で準備すること CircleCIのYAMLファイルに書くシェルスクリプト を説明します。 利用するツール GitHub いわずと知れたGitリポジトリのホスティング 外部サービス連携がやりやすい CircleCI 2.0 GitHub上のリポジトリのイベントと連携してタスクが実行できます PullRequestに連動してテストコードを実行 ブランチのPushに連動してデプロイ
wercker を使って Coq コードを CI する - Qiita
wercker の Coq box をけっこう前に作っていたのでその紹介です。 wercker は Travis CI のような CI as a Service と呼ばれる類の Web サービスです。基本無料です。 wercker では任意のアプリケーションをインストールした環境 (box といいます) を自分で作ることができて、その環境を使って CI をすることができます。 使い方 GitHub または Bitbucket にリポジトリ (Private でも可) を作り、wercker にそのリポジトリを登録します。 Make というファイルを作り、下のように Coq ファイルの名前を書いていきます。 ファイル名は Make でなくてもいいのですが、Coq演習第7回 に「Makeという名前にすることが多い」と書いているとおり ssreflect やその他いろいろなライブラリで Make
EngineYard 上のRailsアプリをWerckerでデプロイする - Qiita
はじめに つい先日まで、EngineYard に Rails でアプリを構築して、自動テストは wercker でおこなっていたものの、デプロイは EngineYard のダッシュボード画面より手動でおこなっていました。 そろそろデプロイも自動化したいと思いましたが、wercker ではデフォルトでは EngineYardへのデプロイに対応していないません。どうも、Codeship というサービスが EngineYard へのデプロイに対応しているということで切り替えました。 しかしフリーでの利用はビルドが100回までという制限があり、実際運用してみると1週間ももたないということがわかり、Codeship の利用をあきらめました（コミットコメントに [skip ci] という文字列を含めると自動ビルドをスキップするという機能はあるのですが、100回という上限を気にしながら開発するのは精神衛
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WerckerでRuby2.1.1を使ってみる(コメント参照) - Qiita
Travis CIでPull Requestではなく、デフォルトブランチのみでコマンドを実行する - Qiita
RailsでElasticSearchとRansack＋CircleCIでの設定でちょっとハマったのでメモ - Qiita
Xcode7系と6系が同居している環境でXcode6.4のXibファイル関係でビルドに失敗する問題への対処（Circle CIも） - Qiita
