CircleCI 2.1 の新機能を使って冗長な config.yml をすっきりさせよう！ – PSYENCE:MEDIA
使うときはコマンド等の中で<< 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
Nuxt.jsで作った静的サイトのビルド/テスト/デプロイを自動化して、毎朝10時に更新する。
AWSとCircleCIの力を借りて、Nuxt.jsで作った静的サイトの運用をできるかぎり自動化した話です。 3ヶ月ほど前からCIのサービスを使うようになり、入門記事はたくさんあって助かったのですが、具体的にどんな感じで使っているかの情報が少なかったので記事にしました。 もしかしたら、CIの使い方が間違っているかもしれないので、そのときは優しくコメントをいただけたら嬉しいです。 できあがった流れ 毎朝10時にLambdaを起こしてデータの更新を行い、静的ファイルを再生成してからデプロイする流れになっています。 対象のサイト ざっくりAWSという、AWSの料金を日本円でざっくり計算できるサイトです。 Nuxt.jsで作成したものを、静的サイトとして生成して、AWSのS3にホスティングしています。 計算に必要なAWSの価格や為替は、毎朝10時に取得したものをS3にJSONで保存し、そのJSON
Docker で Bundler を使って Ruby の gem を作成する方法 - Qiita
プログラミングのツールやサービスは便利なものが揃っているので 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
【iOS】match使わずにCircleCI2.0+FastlaneでFabric配布 - Qiita
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
CircleCI 2.1 の新機能で yaml の記述を DRY にする方法 - 生産性向上ブログ
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
Permission denied (publickey) on Travis.CI - Qiita
はい。タイトルで察した方もおられると思います。やっていきましょう。 Travis.CIは最初にgit clone --recursiveでレポジトリをクローンするため、submoduleがすべて自動的にクローンされていきます。ただ、ここでgitのデータ転送プロトコルとしてsshを使用していると、秘密鍵はレポジトリに置かれていないのでログインに失敗し、結果クローンが失敗します。そしてバッジが赤くなります。 これを何とかする方法として、そもそも常にhttpsを使えばいいんじゃないのという話なんですが、既にgit@...でsubmoduleを登録してしまっているし、CIのことはCIでしたいので、travis.yml上で解決しましょう。 早速ですが解決方法です。以下のtravis.ymlを見て下さい。 この方は何をしているかというと、まずTravisがgit clone --recursiveしな
RailsプロジェクトにささっとCircleCI2.0を導入する - Qiita
はじめに GithubでPull Requetを作成したら、masterにマージする前に自動でビルドされてテストやリンターが走ったら便利。実務ではデプロイツールと連携させたり、AWSやGCP、Slackなどと連携させたりしてさらに効率化を図るけど、ここではCircleCIだけをささっと導入する手順を書く。CircleCIで設定する環境と、実際にアプリを運用する環境をできるだけ合わせることがポイント。手軽に導入できて、設定もYAMLベースでできて簡単なので、CircleCIはとても良い。その他のCIツールとの比較記事はこちら 前提 Githubで管理しているRailsプロジェクトのリポジトリがある CircleCIのアカウントがある CircleCIとGithubを連携してある CircleCIのアカウントがなかったらCircleCIの公式サイトへ行ってサインアップ。CircleCIとGit
CircleCIで、Firebaseのコマンドを実行させる方法 - Qiita
やりたいこと リモートプッシュ時に 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のコード生成をCircleCIで自動化する - Qiita
はじめに 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
GitLab CI/CD vs CircleCI
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
Circle CI 2.0 の設定
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しながらCypressでテスト実行 - Qiita
タイトル通りですが、CircleCIでng serve（Angular）が必要なCypressのテストをする方法です (ドキュメント少ないけどCypressって流行ってないのかなぁ) なぜそんなことをしたいのか jestとかでmock（のデータはあったほうがいいと思うが）を作って、そのmockにmockであることを振る舞わせるのはなんだかテストしているようでしていないような（jest.fn()とか） なんか操り人形を使うことも記述しないといけないのが面倒だし結構複雑になる。。（ごめんなさい初心者です） ので、実際にlocalhostを立ち上げて、ちゃんと振る舞うかテストするのがmockの振る舞いも記述しなくていいのでテストしやすいと思ったのが背景です TL;DR Cypressでヘッドレスなテストを行う CircleCI上でlocalhostを立ち上げる CircleCIでng serve
CircleCI2.1の新機能紹介 - Qiita
パラメタライズされたジョブ定義 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
CircleCI2.0導入まとめ - Qiita
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)」エラーが出てしまうときの解決法 - Qiita
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ページを開く
Java+GradleのアプリケーションをWerckerでビルドとテストする - Qiita
Java+Gradle+Wercker構成でCodecovによるカバレッジチェックする - Qiita
LaravelプロジェクトをCircleCI2.0でUIテストまで行う - Qiita
Travis CIとかtoxとかtestの話 - Qiita
CircleCI 2.0 + Carthage で carthage bootstrap に時間がかかる場合の解決方法 - Qiita
