wercker CIでbundle-installがコケて困った時に - Qiita
cd $WERCKER_SOURCE_DIR $ export WERCKER_STEP_ROOT="/wercker/steps/wercker/bundle-install/1.1.1" $ export WERCKER_STEP_ID="be022acd-9e27-435d-8071-9932df7a776a" $ export WERCKER_STEP_NAME="bundle-install" $ export WERCKER_REPORT_NUMBERS_FILE="$WERCKER_REPORT_DIR/$WERCKER_STEP_ID/numbers.ini" $ export WERCKER_REPORT_MESSAGE_FILE="$WERCKER_REPORT_DIR/$WERCKER_STEP_ID/message.txt" $ export WERCKER_REP
CircleCI, fastlane, DeployGateでAndroidアプリのリリース自動化 - Qiita
概要 個人でAndroidアプリを作ってる中でビルドやリリース作業を自動化したいなと思いました。 色々調べたところ、CircleCI、fastlane、DeployGateを使えばできそうなことがわかったので、 まとめてみようと思いました。 今回参考にするAndroidアプリのソースは下記においてあります。 (パスやAPIキーはprivateリポジトリに隠してあります。) https://github.com/naoto0822/miita-android 目標 ・「Githubで特定のbranchにpushしたらリリース or Beta配布」 そのために下記を順を追って実現します。 コマンド一発でDeploygateアップロード コマンド一発でGoogle Play Storeにアップロード CircleCIでビルド gradleの細かい設定については今回は触れません。 assemble
werckerでのAnsibleとSeverspecの自動実行 - Qiita
注 2016年現在、werckerの仕様変更に伴い、これは動作しません。 概要 GithubへのPush毎に、werckerでAnsibleのPlaybookとServerspecでのテストを自動実行するようにしました。 拙作のansible-Redmineのv3.0.2対応に併せて実現しています。 これまではVagrantを起動して確認していましたが、GithubへのPush毎に自動的に実行されるので、楽になりそうです。 作成にあたっては次のエントリを参考にさせて頂きました。 CircleCIでDockerコンテナに対してansibleを実行しserverspecでテストをする [drone]OSS版DroneでDockerコンテナに対してansibleを実行しserverspecでテストをする エントリと違う点としては、次の3点があります。 wercker以外の別のDockerホストの
Androidのビルドとテストをwerckerで自動化する - Qiita
はじめに 前回のAndroidでコードカバレッジがどんな感じで測れるのかに続き、今回はビルドからテストまでwerckerで自動化する方法をご紹介します。 なお、werkcerのオフィシャルのAndroidのドキュメントはこちらです。 http://wercker.com/android/ サンプルアプリ 前回と同じく、使用しているアプリは次のURLで公開しています。 https://github.com/cattaka/FastCheckList ソースコードの取得には次の様にgitコマンドを使用して取得してください。 なお、サンプルアプリのビルドの成果物は次のURLにデプロイしています。 http://www.cattaka.net/wercker/fastchecklist/ werckerとは werckerとはTravis CIのようなCIのサービスの一種です。2015/01/04
PHPフレームワークphalconのテストをWerckerで自動化してみる - Qiita
概要 そろそろ案件が落ち着いてきて、テストを書き始めたのでCIを導入しようと思ったのと、会社の同僚さんがWercker良いよって話をしてたので使ってみました。 環境について 私の案件はPhalconというPHPのフレームワークを利用しています。 また、gitについてはBitbucketを利用しています。 導入するまで 導入するまでについてです。 wercker.comでアカウントを作成 githubアカウントかメールアドレスの登録 githubかbitbucketを選択画面がでるので、bitbucketを選択 リポジトリを選択 実際に利用してみる テスト用にブランチを作成し、以下のようなwercker.ymlを作成してpushします。 box: duythien/phalcon@1.2.6 build: steps: - script: name: install dependencies
CircleCI 2.0 で Node.js のテストを試す - Qiita
はじめに CircleCI 2.0 のベータ版が使えるようになったので、試しに Node のテストを実行してみました。 従来に比べ柔軟な設定ができるようになっており、非常に好感触でした。 参考 CircleCI 2.0: Beta Access - CircleCI CircleCI 2.0 で何が変わったか ざっくりいうと、任意の Docker イメージを指定し、任意のビルドステップを実行できるようになりました。 同じく Docker ベースの CI である Wercker を使ったことがある方は、それと同じようなものを想像していただければ大丈夫です。 設定ファイルの比較 CircleCI 2.0 では、従来の設定ファイル circle.yml とは、全く異なる形式で .circleci/config.yml に設定ファイルを置きます。 CircleCI 1.0 CircleCI 1.0
Docker-basedなwercker v2を試してみる - Qiita
まえがき Getting started with werckerを読みながら、Docker-basedになってCLIも追加され、便利になった予感がするwerckerを触ってみました。 ドキュメントを端折りながら、とりあえず動かしてみることを優先しています。 準備 必要なツールなど Boot2Docker wercker CLI Virtualenv GitHubのアカウント Virtualenvについてはドキュメントに記載されていませんが、この記事ではVirtualenvを使うことを前提にしています。 Boot2Dockerは boot2docker up した状態にしておいてください。 サンプルアプリ ドキュメントにもあるとおり、wercker/getting-started-pythonを使用します。 最終的にはGithubのリポジトリーをwerckerのappとして登録するので、G
herokuのforkを利用してステージング環境を作成し、CircleCIで自動デプロイする - Qiita
概要 Rails4アプリの本番環境をherokuにデプロイしている。 今まではステージング環境を完全に別アプリとして構築していたが、 forkを使うといい感じにできるらしいので、改めて設定し直してみた。 また、既存のcircle.ymlもそれに合わせて設定し直す。 fork 今回はすでに本番環境があるので、そこからforkしてステージングを作る。 （下記のログを見ると、アドオンや環境変数もコピーされているのが分かる） $ heroku fork --from (APP) --to (APP_FOR_STAGING) Forking (APP)... done. Forked to (APP_FOR_STAGING) Setting buildpacks... done Deploying f4e5b0d to (APP_FOR_STAGING)... done Adding addon p
WerckerでRailsのCIを回す - Qiita
Werkerとは CIサービスはいろいろとあるんですが、BitbucketのPrivateリポジトリで無料でCIを回したくてWerckerを使ってみることにしました。 http://blog.wercker.com/ ymlに設定を書くんですが、書き方がちょっと前に変わったらしく、調べても古い情報と新しい情報が混在していてなかなかに苦戦したのでメモ程度ですが書き残しておきます。 最終的な動作環境 早速ですがまず最終的な設定を晒しておきます。 今回使ったデータベースはMySQLです。 設定ファイル 以下の設定で動きました。（mysqlの環境変数は適当です） box: phusion/passenger-ruby22 services: - id: mysql env: MYSQL_ROOT_PASSWORD: root_password MYSQL_USER: test_user MYSQL
Dockerベースになったwercker v2でRailsアプリをCIしてSlackに通知、herokuにデプロイする手順 - Qiita
2015年4月頃からDockerベースになったCIツールのwercker v2向け設定メモです。 リポジトリ > CI > 通知 > デプロイ と連携して動作するのに各サービスで設定が必要になるので手順をまとめました。 CI環境を作ってテストコードを書いておくとコミットの度に自動的にテストを実行、結果が通知されるので、いつの間にか動かなくなっていた、という状況が避けやすくなります。 1. 自動ビルド〜Slackへの通知設定 1-1. werckerに登録／ログイン werckerのサイトでアカウントを登録してログインします https://app.wercker.com/ 1-2. werckerにアプリケーションを登録 Create > Application からアプリケーションを登録します。 GitHubかBitbucketのリポジトリを登録できます。 リポジトリを選んでそのまま進め
Travis CI 上の環境変数（PULL_REQUEST, BRANCH, TAG）を使って、ワークフローの改善とリリース自動化を実現する - Qiita
CI を中心としたワークフローやリリース（デプロイ）自動化システムを構築するには、現在対象としているコードベースの状態を把握する必要があります ブランチは、feature か master か プルリクエストをマージしたのか タグはついているのか Travis CI でそれらを把握するためには表題にある 3 つの環境変数の意味と組み合わせを理解しないと出来ないのですが、まとまった公式のドキュメントやネット上のレファレンスが見つからなかったので書きます http://aniszczyk.org/2012/04/05/travis-ci/ より Travis CI を使ったリリース自動化の例 例えば、最近試した iOS のプロジェクトでは、次のような、Travis CI を使った比較的複雑な、ワークフローの構築とリリース自動化を行いました なぜこうしているのかという意図などは、リンク先の RE
静的サイトをMetalsmithでビルドし、Github Pagesにwerckerでデプロイする - Qiita
Metalsmithはやりたいことをプラグインで導入していくスタイルなので、若干のとっつきにくさはあるかもしれません。ただ、だいたいの仕組みとよく使うプラグインを把握してしまえばあとは自由にサイトを作ることができるようになってくるので、Node製でそういったものを求めているのであればMetalsmithが最良の選択になりそう。自分が使っているプラグインの可能性もあるけれども、ビルドは他のジェネレータと比較して、それほど早いといった感じはないなので記事数が膨大の場合には微妙なのかもしれない。 hbsnow/4uing.net 自分のサイトも今のところMetalsmithで作成しています。 インストール まずはMetalsmithをインストール。 CLIを使う場合にはグローバルにインストールするのが普通なんだろうけど、CLIは使わないので普通にインストールしていきます。 これだけではほとんど何
CircleCI 2.0は最新版のDockerを使ってdocker buildできる - Qiita
CircleCI 1.0ではDockerのバージョンが1.10.0まででしたがCircleCI 2.0では最新のDockerを使用することができるようになりました CircleCI 2.0にDockerをインストールする 流れとしては以下のようになります 作業用のDockerコンテナを選択する remote dockerをセットアップする docker clientをインストールする circle.ymlに書き起こすとこのようになります version: 2 jobs: build: working_directory: /go/src/github.com/ieee0824/circleci-demo docker: - image: golang:latest steps: - checkout - setup_remote_docker - run: name: install Do
�Ruby on RailsチュートリアルのCIにwercker使いたい - Qiita
Rails勉強中です。いつもお世話になっているRuby on Rails チュートリアルで、CI使ったこと無いので勉強のためにwercker設定してみました。 色々参考にさせて頂き、とりあえずテストが動いてHerokuにデプロイするところまではたどり着いたのでいったんメモします。 Ruby 2.2.0 Rails 4.2.4 PostgreSQL Bitbucket Heroku Deploy Target 今回Deploy先にHerokuを指定したかったけど (na) がついていて何故選択できないのかわからずハマってしまいました。 custom deploy でデプロイできる事は分かったので、以下の環境変数とwercker.ymlファイルを設定し、取り急ぎ動くところまでは確認できました・・・ 環境変数 wercker側で設定した環境変数(Deploy Targetの環境変数で追加しました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://hatebutter.com/link?post_id=5625526
travis-ciを使って、DynamoDBの擬似版dynaliteのDockerイメージを作って公開してみよう！ - Qiita
Travis CI で Swift Package Manager を試す 🚀 - Qiita
CircleCIやTravis CIに頼らず、Coverallsを使う - Qiita
CircleCI 2.0はローカル環境で実行できるよ – Qiita | wqv5mbs062
textlintをTravis CIで動かして継続的に文章をチェックする - Qiita
