dangerをCircleCI上で使ってAndroidのコードを精査する (FindBugs/Android Lint) - Qiita
前回は、PR自体の属性（milestoneとかassignee）に対してのチェックを行いました。 今回は、FindBugsとAndroid Lintの結果を通知してみます。 最終的な差分は こちら のようになりました。 手順 Dangerfileの修正 http://techlife.cookpad.com/entry/2017/06/28/190000 を参考に、下記のような処理を追加しました。 # Findbugs findbugs.gradle_task = "app:findbugs" findbugs.report_file = "app/build/reports/findbugs/findbugs.xml" findbugs.report(true) # Android Lint android_lint.gradle_task = "app:lint" android_li
CircleCI 2.0でGlide管理のGoをGAEにデプロイする - Qiita
FROM golang:1.9.0 ENV _HOME=/root RUN apt-get update RUN apt-get install -y unzip RUN curl https://glide.sh/get | sh RUN mkdir $_HOME/download RUN curl -o $_HOME/download/go_appengine_sdk_1.9.58.zip https://storage.googleapis.com/appengine-sdks/featured/go_appengine_sdk_linux_amd64-1.9.58.zip RUN unzip -q -d $_HOME $_HOME/download/go_appengine_sdk_1.9.58.zip ENV PATH=$_HOME/go_appengine:$PATH RUN
図解: Travis CIの結果をSlack通知する方法 - Qiita
とても参考になる記事 Travis CIとSlackの連携 SlackでTravisCIからの通知を受け取る Travis CIのbuild結果をSlackに通知する いい記事がすでにあるのになぜ書くのか？ 個人的に、Slackの設定画面やメニューを選択するときに、いつもどこにあるか迷ってしまって時間がかかるので、 そうならないように、画像多めでやり方をメモします。 あと、破壊的な.travis.ymlの変更をせずにする方法の紹介です。 本題 まずは、ブラウザで https://<slack-team-name>.slack.com/apps を開きます （僕の場合はぼっちチームなので<slack-team-name>が「nwtgck」というチーム名になので、https://nwtgck.slack.com/apps です） 「travis」と打ち込ので、出てきた「Travis CI」をク
GitHub上のiOSプロジェクトでもTravis CI × CodecovでCIしたい! - Qiita
2017/01/31 追記 CodecovでUIテストのカバレッジがきちんと収集されてないな… と思い調査してみたところ，他のリポジトリでも同様の現象が起こっていたようです． どうやら，XcodeのIDEでUIテストを起動したときと，xcodebuildでCLIでテストを起動したときでは挙動が異なるらしく，それに起因するもののようです． 以下，参照したIssuesです． UITesting not reported - codecov/example-swift Always 0% - nakiostudio/xcov UI Testsのカバレッジ収集以外に関しては，UI Testsの起動含めきちんと想定通りの動作をしております． 2017/06/24 追記 Xcode9においてはこの問題は解決したっぽいです．なので，Xcode9をTravis側がサポートしてくれるようになるとUIテストの
問い合わせフォームもサーバレスでDevOps! (Github,CircleCI,AWS lambda/cognito/ses) 後編 - Qiita
前回の記事で、単純な静的サイトのオートデプロイフローまで完了した後の続き。 後編 「問い合わせフォームもサーバレスでDevOps!」 認証 AWS Cognito 処理 AWS Lambda 通知 AWS SES を利用して、もちろんサーバレスで。 Gibhubへのstaging/masterへのpush のみで、 CircleCI経由で各種環境へ自動デプロイを実現。 前提 前回同様の続きなので、 s3site.proudit.jp -> 本番サイト st.s3site.proudit.jp -> ステージングサイト が、すでにGithub+CircleCiにてデプロイ可能である前提で進める。 構築内容 Cognito準備 フォーム/JavaScript準備 Lambda準備 SES準備 CicriCIデプロイ処理修正 オートデプロイテスト Cognito準備 CognitoはWebアクセ
CircleCI 2.0 で docker-compose を動かすなら、Machine Executor にしないとハマる - Qiita
だが、指定できるのは、パブリックなリポジトリにあるイメージだけなので、プライベートなリポジトリを使っている場合は、このやりかたはつかえない。(正しく動くものとして、これみよがしに Amazon ECR のログインを書いているのはそのため) (2017/09/12 追記) 一番上に追記したように docker image の指定に aws_auth という指定が増えて、ECRのイメージをそのまま使えるようになりました。 「circleci 2.0 docker-compose」でググるとハマる 「circleci 2.0 docker-compose」でググると、以下のようなページがヒットする。 Installing and Using docker-compose How to Build a Docker Image on CircleCI 2.0 ここに罠となるキーワードが登場する。s
CircleCI 2.0のworkflowsを利用していい感じにdocker-composeをcacheする - Qiita
前置き CircleCIのworkflowで上手いことdocker-composeの重い処理をなんとかするのをやってみた。 今回はdocker-composeのbuild処理が重くてtest並列化するとそこがボトルネックになるような場合を想定している。 build自体が重くない場合や並列化が不要な場合は、むしろcache生成・呼び出しで遅くなるパターンもある。 Enabling Docker Layer Cachingなど公式のdockerキャッシュもあるが、machineモードでないとdocker-composeがフルに利用できない（volumesが利用できない）のでsave_cache / restore_cacheを使うやり方を色々ひねった。 手始めにdockerをcacheしてみる docker-composeに飛びつく前に、docker単体のpullとtestをworkflowで
CircleCI 2.0でRe:VIEWの原稿をビルドする - Qiita
CircleCI 2.0が登場し、Dockerイメージを使ってビルドできるようになりました。 C92や技術書典3に向けて執筆されている方でもRe:VIEWを使っている方がいると思います。 vvakameさんが作成したRe:VIEW用のイメージがあるので、CircleCI 2.0でRe:VIEWの原稿をビルドしてみました。 サンプルのリポジトリ: https://github.com/mstssk/ReVIEW_CircleCI_Sample 解説 やったこととしては以前書いたWerckerでRe:VIEWの原稿をビルドするという記事のCircleCI 2.0版です。 GitHubとCircleCI間の連携については、特別なことは何もしていないので本記事では割愛します。 公式のドキュメントなどを参照してください。 設定ファイル 設定ファイルは20行未満になりました。並列処理したりしたいわけで
LaravelをCircleCIでテストしてGAEへ自動デプロイ - Qiita
machine: timezone: Asia/Tokyo php: version: 7.0.4 node: version: 6.3.0 post: - npm install -g npm@3 environment: APP_ENV: testing APP_KEY: "入力してください" DB_HOST: 127.0.0.1 DB_CONNECTION: mysql DB_DATABASE: circle_test DB_USERNAME: ubuntu DB_PASSWORD: "" STORAGE_DIR: /tmp database: override: - "php artisan migrate" - "php artisan db:seed" test: pre: - echo "-----start test-----" override: - vendor/bin
circleci/ruby:2.4.1-node-browsersって何入ってるのか知りたかった - Qiita
printf '#!/bin/sh\nXvfb :99 -screen 0 1280x1024x24 &\nexec "$@"\n' > /tmp/entrypoint && chmod +x /tmp/entrypoint && sudo mv /tmp/entrypoint /docker-entrypoint.sh # (nop) ENV DISPLAY=:99 export CHROMEDRIVER_RELEASE=$(curl --location --fail --retry 3 http://chromedriver.storage.googleapis.com/LATEST_RELEASE) && curl --silent --show-error --location --fail --retry 3 --output /tmp/chromedriver_linux64
Laravel DuskをWerckerで実行する - Qiita
2018-04-12 追記 出来る限りシンプルな構成で Laravel Dusk x Wercker x Headless Chrome のサンプルを新たに作ってみました。 Dockerイメージ Docker Hub GitHub Laravel Dusk サンプル Wercker実行結果 尚、以前のWercker実行結果は誤って削除してしまいました orz 概要 Laravel DuskをWerckerで動かすためのDockerイメージを作成しました。このイメージはDocker Hubで公開してあります。 Laravel Dusk Wercker Docker Hub Werckerで複雑な設定無しに実行できることを意識したので、必要なものが一式揃っているDockerイメージです。主に次の通りです。(シンプルな設定を保ちつつ合理的に分割できるならそうしたい。。。) PHP 7.1.2 P
CircleCI 2.0 (Beta) で Elixir を使う - Qiita
CircleCI 2.0 で Native Docker Support が入った。 ので Elixir も public Docker image を使うと設定が簡単になる。 例えば mix credo, mix test やるとすると、以下でよい。 version: 2 jobs: build: working_directory: ~/my-project docker: - image: elixir steps: - checkout - run: git submodule sync && git submodule update --init - run: mix local.hex --force - run: mix local.rebar --force - run: mix deps.get - run: MIX_ENV=test mix credo - run: m
dangerをCircleCI上で使ってPull Requestを精査する - Qiita
Dangerとは Dangerとは、ざっくり言うと、PRのレビューをするときに、"You Forgot To...(...するのを忘れてませんか？）"と指摘するのを自動化するツールらしいです。 似たようなツールとして、以前から packsaddle/ruby-saddler を使っていたのは、 Androidのコードを自動で解析し、GitHubのpull requestにコメントする - Qiita にも書いていました。 Android開発のコードレビューbotを乗り換えた話 - クックパッド開発者ブログ を読むと、クックパッドさんもDokumiから乗り換えたということで、使ってみました。（ミーハー） （ミーハーついでに、fastlaneとか作ってる Felix Krauseさんが絡んでる？というのも、やってみた要因の一つ） 上記のブログにもDokumi時代の問題点が書かれていましたが、私
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go + Travis CI + Coveralls でCI環境を作る - Qiita
CircleCI 2.0でAndroid関連の静的解析結果をPullRequestで指摘する - Qiita
Circle CI のデプロイ反応を特定のブランチ等で制限したい場合 - Qiita
コンテナベースの環境に移行したTravisでsudoを使わずにtimezoneの設定を行う - Qiita
CircleCI で php.ini の assert.exception を有効にする方法 - Qiita
CircleCIでDockerコンテナをテストしようとしたらエラーになるとき - Qiita
werckerを使っていてローカルではテストが通るのにCIではコケる場合にデバッグする3つの方法 - Qiita
