Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
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
--- version: 2 jobs: generate_cache: machine: true steps: - checkout - restore_cache: key: docker-{{ checksum ".circleci/config.yml" }}-{{ checksum "docker-compose.yml" }}-{{ checksum "Dockerfile" }} paths: ~/caches/images.tar - run: name: Check cache file, if not exists then pull images and generate cache. command: | if [ ! -f ~/caches/images.tar ]; then docker-compose pull sample-mysql docker-co
2017/01/16 (月) 追記: CircleCI の公式ドキュメントに yarn の導入方法が明記されています。今後はそちらに合わせるのがベターです。 Install and Use Yarn (the NPM replacement) on CircleCI - CircleCI これまで行っていた設定だと、yarn のパッケージインストールのタイミングで「すでに yarn がインストール済み」とエラーが発生するようになってしまいました。よって以下は古い記事なので、読み飛ばしてください。 要約すると yarn 0.17.x から、キャッシュ保存先が OS によって変わる ようになった! CI で ~/.yarn-cache/ をキャッシュする設定を入れている場合、正しいパスに変える必要がある ~/.cache/yarn/ (Linux の場合) 事の流れ 先週あたりから、npm に
version: 2 workspace_root: &workspace_root ~/workspace defaults: &defaults docker: - image: circleci/ruby:2.4.2-node-browsers environment: RAILS_ENV: test BUNDLE_JOBS: 3 BUNDLE_RETRY: 3 BUNDLE_PATH: vendor/bundle DB_HOST: 127.0.0.1 - image: circleci/mysql:5.7 working_directory: *workspace_root attach_workspace: &attach_workspace attach_workspace: at: *workspace_root jobs: build: <<: *defaults step
自分のブログに書いたけれども誰にも見られてなくて悲しかったので転載しました。 http://selmertsx.hatenablog.com/entry/2017/11/20/192719 概要 自分がいるプロダクトでCircleCI 2.0 の導入をすることになった。 恥ずかしいことにCircleCIの設定を自分でしたことが無かったので、設定を簡単にする方法を探した。 公式ドキュメントを読んでいたら、circleci をlocalで動かす方法が見つかったのでやってみた。 その結果、10minくらいで簡単に動かせることが分かった。 このドキュメントには、circleciをlocalで動かす方法と、localで動かす際の注意点を記載する。 基本的には、このドキュメントからの抜粋なので、疑問に思ったらそっちを見て頂けると 手順 circleciコマンドのインストール circleci 2.0用
$ firebase login:ci Visit this URL on any device to log in: ************* Waiting for authentication... ✔ Success! Use this token to login on a CI server: *************(トークンがここに表示される) Example: firebase deploy --token "$FIREBASE_TOKEN" ブラウザが開き,Google認証を通すとトークンが発行されコマンドの出力として表示されます. Circle CIのビルド環境変数を追加 プロジェクト設定のBUILD SETTINGS > Environment Variablesで先程発行されたトークンと,プロジェクトIDを登録しておきます. circle.ymlの作成 dep
CircleCIで"Container ID xxxxxx cannot be mapped to a host ID"なエラーが出た場合、Dockerイメージ側でtarコマンドを使っていないか確認すると問題が解決するかもtarCircleCIDocker CircleCIでDockerのホストマシンとコンテナのUID/GIDのマッピングにはマッピング可能な範囲がある。マッピング可能な範囲外のUID/GIDがDockerイメージ内にあるとContainer ID xxxxxx cannot be mapped to a host IDなエラーになる ( 参考URL: Debugging Container ID Cannot Be Mapped to Host ID Error ) ところで、Dockerイメージを作るときは(大抵普段は使わない)rootでの操作をすることが多い。 root
最近Githubを使用して、卒論をバージョン管理させるようにしました。(それまではGistでtexファイルのみ管理してました。) しかし、そろそろ最終提出ということで、 こまめに研究室サーバへ進捗をアップロードしなくてはならなくなったため、CircleCIで自動化させるようにしました。 ※ 追記 : 2018/01/23 uploadスクリプト内でgit configでパスワード指定していた箇所を修正しました。 構成 git push ➜ uploadスクリプト実行 ここが一番ハマりました。 というのも、最初git hookのpost-receiveを使ってやろうとしていたからです。 参考 : git hookでサイトを更新、やってみた 数時間、post-receiveの処理が呼ばれないと唸って、 詳しい友達に聞いたところ、Githubは出来ないからGitHub Webhookか、CIを使
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
2018年8月31日を最後に、CircleCI 1.0が使えなくなることがアナウンスされました。 See: CircleCI 1.0 End of Life on August 31, 2018 社内向けに展開していたのですが、需要がありそうなので公開してみます。 ハマったポイント 1. rspec_junit_formatter がロードできないと言われる $ #!/bin/bash -eo pipefail bundle exec rspec --profile 10 \ --format RspecJunitFormatter \ --format progress \ --out test_results/rspec.xml \ $(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=t
はじめに Travis CI上でMySQLを使う方法を調べたので自分用にメモ。公式サイトと以下のエントリを参考にさせていただきました。この記事ではRubyとRSpecを使っていますが、他の言語やテスティングフレームワークでもほぼ同じだと思います。 https://docs.travis-ci.com/user/database-setup/ http://qiita.com/suzuki86/items/e9682a242cad52003b08 設定手順 Travis CI上でユーザー名root(travisユーザーでも良いが権限がやや制限される)、パスワードなしでログインできる環境が自動的に立ち上がるため、こちら側で必要なのはテスト用データベース、テーブルの作成とdatabase.ymlの設定のみ .travis.ymlの設定 before_scriptに直接SQLを書いてもいいのですが
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Excelで書かれた手順書をゴニョゴニョするの本当に嫌だなと思ったので、なんとかもうちょっと生産的に仕事が出来ないかと思ってこの記事を書きました。構想の半分は妄想で出来ています。 追記 内容少し減量してまとめたやつを自社ブログでも執筆・掲載してみました。よければこちらも。 ちょっとしたネタはこっちで細々執筆していく予定です 2018/02/26 制作物の公開 Excelやめたい方、多いみたいですね。それなりに影響があったようで私も嬉しいです。現状のブツですが、制作物があるので以下でリンクを貼っておきます。 S3 Website Host
CircleCI? CircleCI 流行りのCIサービスです。 GitHub / BitBucketのPUSHに反応して、コードをゴニョゴニョします。 お金かかるの? Pricing and Plan Information - CircleCI 1コンテナは無料です。 privateリポジトリでも、です。 つまり、ビルドに時間がかかっても良いなら、無料で使い続けられます。 ただし OS Xのコンテナは有料です。 iOSアプリのCIには、お金が必要です。 つづき 仕事としてフルタイム使うと、1日5〜10ビルドは最低必要なので、$129/monthは必要です。 複数人で開発とかしてると、もう一つ上の$249/monthぐらいが必要かも。 なにをやらせるか circle.ymlというファイルを、リポジトリのルートに置いておきます。 そこに実行させたいコマンドや、環境の指定を書いておくと、それ
2019年7月にGitHubにマージしたブランチが自動削除される機能が入ったためこの記事は内容の非推奨です。 Automatically delete head branches of pull requests - GitHub Changelog ブランチの自動的削除を管理する - GitHub Docs 以下は古い記述 前置き マージ済のブランチは基本的に消しても問題ないので、GitHub上には進行中のブランチだけがあるきれいな状態に保ちたいところ。 PRをマージした後にブランチを消すボタンが出るんですが、チームで開発してるとどうしても消し忘れる人が1人はいるので 1CircleCIで定期的に消すようにしました 前提 GitHub CircleCI 2.0 準備 GitHubにpushするための権限が必要なので「Settings -> Checkout SSH keys」でuser
2019年7月にGitHubにマージしたブランチが自動削除される機能が入ったためこの記事は内容の非推奨です。 Automatically delete head branches of pull requests - GitHub Changelog ブランチの自動的削除を管理する - GitHub Docs 以下は古い記述 前置き マージ済のブランチは基本的に消しても問題ないので、GitHub上には進行中のブランチだけがあるきれいな状態に保ちたいところ。 PRをマージした後にブランチを消すボタンが出るんですが、チームで開発してるとどうしても消し忘れる人が1人はいるので 1CircleCIで定期的に消すようにしました 前提 GitHub CircleCI 2.0 準備 GitHubにpushするための権限が必要なので「Settings -> Checkout SSH keys」でuser
はじめに 3月23日(木)に行われたGotanda.mobile #2で発表した内容になります。 LT資料: AndroidアプリをOSSで運用してみる // Speaker Deck yamacraft/android.RequestPermissions: RequestPermissions動作確認用サンプルプロジェクト 概要 個人開発しているAndroidアプリをOSSとして運用する上で、「公に見せたくない情報の管理をどうするか」という懸念点があると思います。 今回はその中でbuild.gradle内の情報の一部をリポジトリ上で見えない形で運用する方法の一部を共有します。 あくまでもこれが正解なのかどうかわからないので、より良い方法があればコメントなどにご意見おねがいします! local.propertiesによるテキストの保存 Androidプロジェクトで「リポジトリに残したくな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く