Using Workspaces to Share Data between Jobs - CircleCI
Workflows each have an associated workspace. Workspaces are used to transfer data to downstream jobs as the workflow progresses. Use workspaces to pass along data that is unique to a workflow and is needed for downstream jobs. Workflows that include jobs running on multiple branches may require data to be shared using workspaces. Workspaces are also useful for projects in which compiled data are u
CircleCI 2.0 で PostgreSQL を使う時のチューニング小ネタメモ - Qiita
CircleCI 2.0 のドキュメントに書かれている小ネタですが、つい最近まで知らず、試してみたので紹介します。 TL;DR データベースディレクトリに tmpfs を使う Docker イメージもあるよ(circleci/postgres:*-ram) tmpfs を使わない版では書き込み性能のチューニングがされているよ 普通の書き込みでは差が出ないみたいだよ CircleCI 曰く tmpfs をマウントしたディレクトリを PostgreSQL のデータベースディレクトリとして利用する事で、テスト実行時間を短縮出来る可能性があります、とのこと。 Optimizing Postgres Images The circleci/postgres Docker image uses regular persistent storage on disk. Using tmpfs may ma
circleci tests split --split-by=timingsについて調べた・自作してみた ·
この記事はCircleCI Advent Calendar 2018の24日目の記事です。 テスト分割実行ファンの皆さんこんにちは。 今回はCircleCIの並列テストにおいて、いい感じにテストファイルを分割することを考えていきたいと思います。 【イメージ アニgif】 テストファイルをいい感じに分割したい まず前提として、「いい感じに分割したい」とはどういうことかということを説明します。 例えば今、テストファイルが7個あって、それぞれのテストにかかる時間が経験上「10秒、6秒、5秒、4秒、3秒、2秒かかる」ということがわかっているとします。 この場合、普通に1プロセスで実行すると10+6+5+4+3+2で30秒かかります。 ここで、CircleCIでparallelism: 3(3並列)で分割テストすることを考えます。 まず悪い例として「[10, 3], [6, 5], [4, 2]」と
HugoのページをCircleCIでbuildしてGithub Pagesにアップする - komagataのブログ
8年振りに会社ページがリニューアルされました。 Fjord, LLC hugoで作ってGithub Pagesで公開しています。 デザインに関しては@machidaさんの記事をご覧ください。 会社サイトをリニューアルしました | FJORD, LLC(合同会社フィヨルド) デザインもhugoも@machidaさんがやったので僕はほとんど何もやってないですが、 「ページをpushするとCircleCIでbuildしてアップ」 という部分だけやりました。 fjordllc/fjordllcリポジトリのsourceブランチにmarkdownの記事ファイルをアップするとCircleCIがhugoでbuildしてmasterにpushします。 masterブランチのdocsディレクトリがGithub Pagesで公開されるようになっています。 CircleCIのcircle.yml general:
How CircleCI Processes 4.5 Million Builds Per Month - CircleCI Tech Stack
CircleCI’s continuous integration and delivery platform helps software teams rapidly release code with confidence by automating the build, test, and deploy process. CircleCI offers a modern software development platform that lets teams ramp quickly, scale easily, and build confidently every day. By Rob Zuber, CTO at CircleCI. Background CircleCI is a platform for continuous integration and deliver
rubyのRPMを作るのをDockerとCircleCIにやらせたら便利だった - critical alertのブログ
この記事はフィードフォースエンジニア Advent Calendar 2015 - Adventar4日目です！ みなさんrubyのRPMビルドってどうしてますか！ CentOSをメインで使っていると最新のrubyはyumで入らないのでどこかのリポジトリからインストールするか自前でビルドする必要があるかと思います。 プロビジョニングのタイミングでrbenvやmakeで入れてもいいのですがciや新規ホストを立てた時など毎回rubyのビルドをするので時間がかかってしまうんですよね。 それが嫌でrubyはリリースされるたびにrpm化してインストールするようにしています。 ところがrpmのビルド環境って用意するのが面倒だったりビルドしたい環境ごとにvagrantを立ち上げて〜とか意外と手間がかかる。 自動化したいなーと思っていて、Dockerは特定の環境を再現するのに最適だし、CircleCIはG
CircleCI経由でRailsアプリをデプロイ - Qiita
最近CircleCIもprivate repoのビルドが無料になった。（1コンテナまで） せっかくなので使ってみようということで、 Railsアプリのビルド実行に使うサービスをwerckerから乗り換えてみた。その設定などのメモ。 Continuous Integration and Deployment on CircleCI just got better: now it’s free. | The Circle Blog 設定ファイル 他のCIサービスと同じく、基本的にRailsプロジェクトのルートディレクトリに置いたyamlファイル(circle.yml)に記述していく。 設定については、ドキュメント見れば詳しく書いている。 Configuring CircleCI - CircleCI 凝ったことをする必要がなければ、そんなに設定をいっぱい書かずともビルドとデプロイができる印象。
Jenkinsと完全にサヨナラして、CircleCIに移行した話 - tehepero note(・ω<)
2015-07-02 Jenkinsと完全にサヨナラして、CircleCIに移行した話 CI Jenkins CircleCI 長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって（それなりにスペック高くて、slaveもぶら下がってる）、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用
DNSimpleをTerraform+GitHub+CircleCIで管理する - Qiita
処理の流れとしては次のような感じ。 GitHubにpushされるとCircleCI上でterraform planが走る そのPRがmasterにマージされるとterraform applyが走る Terraformのテンプレート まずはdnsimpleプロバイダについて記述する。 variable "dnsimple_email" {} # 環境変数TF_VAR_dnsimple_email variable "dnsimple_token" {} # 環境変数TF_VAR_dnsimple_token provider "dnsimple" { token = "${var.dnsimple_token}" email = "${var.dnsimple_email}" } DNSimpleに接続する際のtokenとemailをTerraformに渡す必要があるのだけれど、それらはリポ
CircleCIアンチパターン 2015春 - tehepero note(・ω<)
2015-03-31 CircleCIアンチパターン 2015春 CI CircleCI Docker 今日はCircleCIで気持ちよくCIを回すために、抑えておいた方が良いアンチパターンについて書きます。わりと基本的な話なので、心当たりがあれば見直してみると良いと思います。 Fat Repository Anti Pattern（巨大なリポジトリ） CircleCIのコンテナは使い捨てですが、対象のリポジトリを毎回cloneするのではなくて、2回目移行は前回のCI時にキャッシュしておいたリポジトリを利用することで差分取得を実現しています。 checkoutフェーズのRestore source cacheのことですね。 この手法によって最新取得のコストを大幅に低減することができますが、コンテナ初期化時にS3からリポジトリのアーカイブを取得するという特性上、あまりにも巨大な数GB超えのリ
CircleCIで任意のツールをインストールして使う際の定番スニペット - tehepero note(・ω<)
2015-03-05 CircleCIで任意のツールをインストールして使う際の定番スニペット CircleCI CI 春ですね！というわけで懲りずにCircleCIネタを投下していきます。 CircleCIのコンテナにはJavaやらNodeやらRubyとかのランタイムがあらかじめセットアップされていますが、当然欲しいものがなかったりするので自分でコンテナにセットアップしてやる必要があります。しかし、CircleCIのコンテナはビルドが終われば破棄されてしまうので、毎度コンテナを立ち上げるためにセットアップしてやらなくてはなりません。 独自にツールをインストールする際に留意するべき点は以下のことですね。 cache_directoriesを使い、2回目ビルド以降のダウンロードをしない cacheをリストアしたディレクトリが空であれば、ダウンロードしてアーカイブを展開 ツールを使うための必要な
Rails + CircleCI で MySQL の utf8mb4 をつかう - きりきりやま
前提 ActiveRecordをutf8mb4で動かす - Qiita 気合でコンテナ上の MySQL の設定を変更する circle.yml database: override: - mysql -u root -e 'set global innodb_file_format = Barracuda' - mysql -u root -e 'set global innodb_file_per_table = 1' - mysql -u root -e 'set global innodb_large_prefix = 1' - bundle exec rake db:create db:schema:load --trace
Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
大晦日〜正月にiOSでCircleCIを試したので振り返ってみた - Qiita
はじめに 皆様、新年あけましておめでとうございます 今年も不定期に思いつきで記事をあげていくのでよろしくお願いいたしますm(_ _)m 昨今TravisCIに代表されるCIサービスが流行ってますね。 Rettyでは内製JenkinsでCIを頑張っているのですが、CircleCIでiOSのBetaできるよって公式ドキュメントを見つけたので、大晦日〜正月にかけてトライしてみました。 だいぶ記事が長いので「結論から知りたい」という方はこちらのまとめから御覧くださいませ。 CircleCI事始め アカウントの作成 まずはアカウントを作ります。 アカウントはGithub認証を利用したものになるため、Githubアカウントがないと登録できません。 CircleCIのアカウント作成はこちらからどうぞ。 対象リポジトリの選択 登録したらまずはCI対象にするリポジトリを選びます。 アカウントにOrganiz
Route53のレコードをRoadworkerとCircleCIを使ってPull Requestベースで管理する
手元でRoute53のレコードを管理したいんだけど、Roadworkerを使ってRoutefileがPull Requestでマージされたときに自動で行われるようになれば、コメント付きの履歴がとれつつ実際の状態とリポジトリ上のファイルとの一貫性がとれていいのかなと思ってやってみた。 必要なもの CircleCIのアカウント Travis CIでも同様のことはできると思う。ただ今回プライベートリポジトリを扱いたかったので、無料で1枠使えるCircleCIで試してみた。 Route53のfull access権限のあるIAMユーザのAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEY RoadworkerのRoutefile 現在の状態をroadworker -e -o RoutefileコマンドでRoutefileに書きだす 前述のRoute53の鍵を~/.aws/
ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
CircleCIでfeature branchをHerokuに継続deploy - Masatomo Nakano Blog
最近CIサーバーを自前Jenkinsから CircleCI に移した。CircleCIとても便利で簡単なのでオススメ。 CircleCIには普通のheroku deployは内蔵されているのだけど、 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 、をやるにはちょっと工夫が必要。 色々書こうと思ったけど、めんどくさくなったのでscriptを晒しておくだけにしよう！ この中で使われているスクリプト関連、特に秘密にする部分もないのでpublicでgithubに置いている。 https://github.com/quipper/deploy-support-tools /circleci.yml deployment: feature: branch: /^(?!^master$).+$/ commands: - ./script/staging_deploy.sh pro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Install and configure the CircleCI local CLI - CircleCI
why-we-broke-our-philosophical-vows-to-bring-you-circleci-2-0
Configuration reference - CircleCI