※ 12/19 以前、githubのアクセストークンの設定のところを自分のアカウントと書いてて、リンクしていただいた@chamaoさんの記事を見て、 「あっ」って、なったので文章を一部修正、スクリーンショットの追加をしました。 導入した理由 プロジェクトによって「この作業やった時は、必ず前に〜つけて」みたいなルールが違うところがあったり、覚えるのが大変。。。 「お前それ、あげる前にちゃんと動かした？」、「TODO残ってるんだけど？？？」みたいなことを逐一言うのは正直疲れるし、実装以外の部分の指摘をするためにコミット内容に目を通すのも時間がかかる。 少しでも「何か忘れてない？」チェックの負担を軽減できないかと思い、DengerFileと言うファイルで設定したルールの通りに自動チェックをしてくれる Dangerを導入をしてみた。 ※この記事は、CircleCI2.0が扱えると言う前提として書い
今月24日発売のWEB+DB PRESS Vol.107に実践CircleCIという特集を寄稿しました。WEB+DBへの寄稿は、Vol.58のEmacs、Vol.86のAtomに続いて3回目となりますが、初めてエディタ以外の内容で記事を書かせてもらいました。 なぜCircleCI特集を書いたのか。 今回、WEB+DBにCircleCI特集を書いた一番理由は、WEB+DBの献本者リストから外れてしまったため、何か寄稿しなければWEB+BDが貰えなくなってしまったからというのが大きな理由です。 WEB+BDでは、原稿を書くと献本者リストにリストアップされ、しばらくの間、献本が行われるという素晴しい仕組みがあるのですが、献本者リストには定員があり、古い人から順番に卒業してしまう制度となっています。前回、寄稿したのが2015年だったのですが、それから約3年が経ち、ついに2010年の寄稿から初めて献
使うときはコマンド等の中で<< parameters.パラメータ名 >>と書いてやると渡ってきたパラメータが展開されます。また <<# parameters.パラメータ名 >>hogehoge<</ parameters.パラメータ名 >>と書くとparameters.パラメータ名が真の場合にブロックの中身（hoghoge）が展開されます。真偽の判定については後述するConditional Stepsを参考にしてください。 今回の例では deploy_dev、deploy_stg、deploy_prodの３つのジョブはnpm run deploy:の後に指定するパラメータ以外はすべて同じなのでdeployジョブとしてまとめてみます。 version: 2.1 executors: default: working_directory: ~/workspace docker: - image
AWSとCircleCIの力を借りて、Nuxt.jsで作った静的サイトの運用をできるかぎり自動化した話です。 3ヶ月ほど前からCIのサービスを使うようになり、入門記事はたくさんあって助かったのですが、具体的にどんな感じで使っているかの情報が少なかったので記事にしました。 もしかしたら、CIの使い方が間違っているかもしれないので、そのときは優しくコメントをいただけたら嬉しいです。 できあがった流れ 毎朝10時にLambdaを起こしてデータの更新を行い、静的ファイルを再生成してからデプロイする流れになっています。 対象のサイト ざっくりAWSという、AWSの料金を日本円でざっくり計算できるサイトです。 Nuxt.jsで作成したものを、静的サイトとして生成して、AWSのS3にホスティングしています。 計算に必要なAWSの価格や為替は、毎朝10時に取得したものをS3にJSONで保存し、そのJSON
プログラミングのツールやサービスは便利なものが揃っているので Ruby の gem を作りながら紹介します。 Docker なので OS X, Windows, Linux で動作します。 gem は Ruby の外部ライブラリです。 すること、できること Docker の Ruby で gem をテスト駆動開発で作ります。 CircleCI や CodeClimate のサービスで自動テストをします。 GitHub や RubyGems にリリースした gem を使います。 GitHub の利用 GitHub はソースコードを管理するサービスです。 今回は my_gems という名前の gem を作るので my_gems のリポジトリを作ります。 リポジトリを作ると続きはターミナルでコマンドラインを使います。 git init コマンドで空の README を追加をして、git conf
references: defaults: &defaults macos: xcode: "X.X.X" working_directory: ~/project shell: /bin/bash --login -eo pipefail environment: TZ: "/usr/share/zoneinfo/Asia/Tokyo" LANG: en_US.UTF-8 LC_ALL: en_US.UTF-8 version: 2 jobs: build: <<: *defaults branches: only: - develop environment: FASTLANE_LANE: crashlytics_stg steps: - checkout: path: ~/project - run: name: Set Ruby Version command: echo "rub
github.com まだプレビューですが CircleCI の新機能が 2.1 として使えるようになっているという話と、2.1 の新機能で yaml の設定を DRY にする方法を紹介します。 長いので目次。 2.0 までの DRY な yaml を書く方法 2.1 を有効にする方法 2.1 の新機能 Commands Executors ジョブのパラメータ化＆ワークフロー内での複数回実行 Conditional Steps Orb CLI の変更 まとめ 2.0 までの DRY な yaml を書く方法 2.0 までは CircleCI の yaml の設定を DRY にしようとすると yaml のエイリアスを使う必要がありました。 例えば、node.js のプロジェクトで node の複数バージョンでビルドする設定をエイリアスで DRY にしようとすると次のようになります。 node
はじめに GithubでPull Requetを作成したら、masterにマージする前に自動でビルドされてテストやリンターが走ったら便利。実務ではデプロイツールと連携させたり、AWSやGCP、Slackなどと連携させたりしてさらに効率化を図るけど、ここではCircleCIだけをささっと導入する手順を書く。CircleCIで設定する環境と、実際にアプリを運用する環境をできるだけ合わせることがポイント。手軽に導入できて、設定もYAMLベースでできて簡単なので、CircleCIはとても良い。その他のCIツールとの比較記事はこちら 前提 Githubで管理しているRailsプロジェクトのリポジトリがある CircleCIのアカウントがある CircleCIとGithubを連携してある CircleCIのアカウントがなかったらCircleCIの公式サイトへ行ってサインアップ。CircleCIとGit
やりたいこと リモートプッシュ時に Firebase のデプロイコマンドを実行したい つまづいたこと CircleCI環境下で、firebase のコマンド実行につまづいた 解決法 CI環境下で、Firebase のデプロイをしたいので、firebase-toolsをインストールする必要があります。 最初に、グローバルでインストールしようとしましたが、CircleCI環境下では、それが許可されていません。(そりゃそうか) $ #!/bin/bash -eo pipefail npm install -g firebase-tools npm WARN checkPermissions Missing write access to /usr/local/lib/node_modules npm ERR! path /usr/local/lib/node_modules npm ERR! c
はじめに gRPCではクライアントとサーバーのインターフェースを一致させる事ができますが クライアントとスタブのコード生成がずれると通信できなくなります。 また各言語向けのprotocol buffer compilerを環境構築するのは面倒です。 そこで諸々の環境が揃ったDockerイメージのnamely/protoc-allとCircleCIを組合せてコード生成を自動化します。 構成 以下の図とブランチ構成でコード生成の自動化を行います。 masterブランチ .circleci/config.yml docker-compose.yml protos/echo.proto Go用のgenerated/goブランチ C#用のgenerated/csharpブランチ また実際の試したものは以下のリポジトリに置いています。 https://github.com/shiena/grpc-ge
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに GitLab CI/CDとCircleCIの違いを比較する記事です。 GitLab CI/CDって何？ GitLab has integrated CI/CD pipelines to build, test, deploy, and monitor your code Rated #1 in the Forrester CI Wave™ Forresterに認められたNo.1 CIサービス。 GitLab supports development teams with a well-documented installati
Posted on July 21, 2018 authored by Shinya Yamaguchi Last Updated July 23, 2018 はじめに Haskell プロジェクトの多くは Travis CI を使って CI を回しています。 しかしここ最近、いくつかのプロジェクトで Circle CI の利用が進んでいるように思います。 僕も社内のプロジェクトでは Circle CI を使っています。実際に Circle CI を使っていて個人的に良いなと感じたのは以下の4点です。 docker イメージを指定できる プライベートリポジトリで利用できる travis より速い気がする キャッシュが不変 キャッシュの動作に関しては travis とは逆なので少し違和感があるかもしれませんが、キャッシュでCIが失敗するということが無くなるので、非常に良いと思います。 今回は
タイトル通りですが、CircleCIでng serve（Angular）が必要なCypressのテストをする方法です (ドキュメント少ないけどCypressって流行ってないのかなぁ) なぜそんなことをしたいのか jestとかでmock（のデータはあったほうがいいと思うが）を作って、そのmockにmockであることを振る舞わせるのはなんだかテストしているようでしていないような（jest.fn()とか） なんか操り人形を使うことも記述しないといけないのが面倒だし結構複雑になる。。（ごめんなさい初心者です） ので、実際にlocalhostを立ち上げて、ちゃんと振る舞うかテストするのがmockの振る舞いも記述しなくていいのでテストしやすいと思ったのが背景です TL;DR Cypressでヘッドレスなテストを行う CircleCI上でlocalhostを立ち上げる CircleCIでng serve
パラメタライズされたジョブ定義 doc: https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/jobs.md カスタムコマンドでも利用できたパラメータ指定がジョブでも出来るようになっています。 これによって、例えば「同じ一連のテストを異なるNode.jsのバージョンごとに実施」みたいなことがやりやすくなってます。 jobのパラメータを利用するときの注意点として、組み込みのパラメータ（ pre-steps , post-steps )があるので、これらは使えないようです。 pre-steps , post-stepsについてはこちらを参照のこと。 executor定義 doc: https://github.com/CircleCI-P
CircleCIを以下のような構成で導入してみた際のまとめ 事前準備 githubにリポジトリがある githubの秘密鍵・公開鍵を持っている githubに公開鍵が登録されている ec2の秘密鍵を持っている ec2に公開鍵が登録されている(authorized_keys) 必要な作業 CircleCIに登録する 管理画面から該当のリポジトリを追加する CircleCIに公開サーバのssh keyを登録する .circleci/config.yml作る プッシュする ビルドを確認する 1. CircleCIに登録する 今回はGitHubでSign Upし連携します。 https://circleci.com/signup/ 2. 該当のプロジェクトを追加する ADD PROJECTから追加します。 3. CircleCIに公開サーバのssh keyを登録する 今回はec2になるので、ec2
CircleCI2.0でphp.iniのmemory_limitを変更しても「Allowed memory size of xxx bytes exhausted (tried to allocate xxx bytes)」エラーが出てしまうときの解決法PHPMySQLCircleCICircleCI2.0 CircleCI2.0でのPHPアプリケーションのビルドで、あるとき「Allowed memory size of xxx bytes exhausted (tried to allocate xxx bytes)」というエラーがPHPUnitのテストで発生するようになりました。 そのときかなりハマったので備忘録として残します。 TL;DR MySQLのmax_allowed_packetが足りていないのが原因で、MySQLのDockerイメージに引数でmax_allowed_pack
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
