以前に Jenkins を公式の Docker イメージから構築する方法について書きましたが、今回は公式の Docker イメージに事前にプラグインをインストールした Docker イメージを作成する方法について書きます。
ちなみに、公式の説明は Docker イメージの GitHub リポジトリの README.md に書いてあります。
CircleCI 2.0 で Workflow の triggers を使って定期実行ジョブ（Nightly Builds）を実現する
過去に、『CircleCI 2.0 で定期実行ジョブ（Nightly Builds）を実現する』という記事を書いたのですが、現在の CircleCI 2.0 ではもっと楽に cron 的な定期実行ジョブを記述できるようになっているので補足記事を書きます。
前の記事を書いた時点では CircleCI 自体にジョブ実行タイミングをスケジュールする機能がなかったので、外部の Lambda なりなんなりを使って API を叩くという遠回しな手段をとっていましたが、今では Workflows に "triggers" という構文が追加されているので、CircleCI のみで完結して定期実行ジョブを記述できるようになっています。
↑の記事を見てもらうのが一番わかりやすいと思いますが、英語しかないので一応こちらでも解説します。
version: 2
jobs:
build:
docker:
- image: buildpack-deps:trusty
steps:
- run:
command: echo 'build'
nightly-build:
docker:
- image: buildpack-deps:trusty
steps:
- run:
command: echo 'nightly-build'
workflows:
version: 2
commit-workflow:
jobs:
- build
scheduled-workflow:
triggers:
- schedule:
cron: "0 1 * * *"
filters:
branches:
only:
- master
jobs:
- nightly-build
上記の設定ですと、以下の 2 つのジョブが設定されます。
- コミット時に commit-workflow が開始され、その中で build ジョブが実行されることにより "build" と echo される
- 日本時間で毎日午前 10 時（UTC で毎日午前 1 時）に schedule-workflow が開始され、その中で nightly-build ジョブが実行されることにより "nightly-build" と echo される
triggers 構文は、workflows の中でのみ記述できる設定です。これを書かなければこれまで通りコミット時に実行されます。
schedule の中に書かれている cron に、 crontab で使われるのと同じ書式で実行タイミングを記述します。UTC として解釈されるので注意が必要です。filters も必須パラメータで、どのブランチに対して実行するかを制限します。
前回の記事と比較して、こちらのほうが直観的ですし、圧倒的に楽になりました。CircleCI はユーザーがほしい機能を着実に実装してくれるイメージがあるので、今後も楽しみです。
Selenium ユーザー視点で Cypress を試したらめちゃくちゃ便利そうでした
この記事は、Selenium/Appium Advent Calendar 2017 の 23 日目です。
この記事では、ブラウザテストツールの Cypress の紹介を Selenium ユーザーである自分の視点から書きます。
Cypress とは
Cypress は、テストのセットアップ、作成、実行、デバッグなどをシンプルにするブラウザテストツールです。E2E テストを既存の Selenium のようなツールで実装・運用するときにありがちな辛い体験を改善して、開発者を幸せにすることが目的のようです。
Cypress は、3 年以上の間 private beta だったのですが、今年の 10 月に public beta になり、そのタイミングで大半が OSS となりました。
Cypress は、ThoughtWorks 社の Technology Radar の今年 11 月に更新されたバージョンの Tools 部門で ASSESS（調査する価値がある）として位置づけられています。
続きを読むCircleCI 2.0 で Docker イメージをビルドして Docker Hub に push する
CircleCI 2.0 の小ネタです。
TL; DR
リポジトリのルートに Dockerfile がある前提です。
- CircleCI 2.0 で対象のリポジトリをプロジェクトとして有効にする
- CircleCI 2.0 上で環境変数に Docker Hub のユーザー名を
DOCKER_USERに、パスワードをDOCKER_PASSに登録する .circleci/config.ymlに以下のように記述する
version: 2
jobs:
build:
docker:
- image: docker:17.07.0-ce-git
steps:
- checkout
- setup_remote_docker
- run:
command: docker build -t miyajan/test-circleci-docker .
- run:
command: docker login -u ${DOCKER_USER} -p ${DOCKER_PASS}
- run:
command: docker push miyajan/test-circleci-docker
もう少し実用的に、セマンティックバージョンのタグ（1.0.1とか）が作成されたときだけ Docker イメージの build & push を行いたい場合は以下のようになります。
version: 2
jobs:
buildh:
docker:
- image: docker:17.07.0-ce-git
steps:
- checkout
- setup_remote_docker
- run:
command: docker build -t miyajan/test-circleci-docker:${CIRCLE_TAG} .
- run:
command: docker login -u ${DOCKER_USER} -p ${DOCKER_PASS}
- run:
command: docker push miyajan/test-circleci-docker:${CIRCLE_TAG}
workflows:
version: 2
build:
jobs:
- build:
filters:
branches:
ignore: /.*/
tags:
only: /^[0-9]+\.[0-9]+\.[0-9]+$/
説明
CircleCI で Docker イメージの build を扱うための公式ドキュメントは以下にあります。
setup_remote_docker のステップを実行すると、Docker Engine 用のホストがリモートに立ち上がります。これ以降のステップの実行も image で指定されたメインのコンテナの中で実行されますが、docker コマンドは
TCP 経由でリモートホストの Docker Engine を使用するようです。これは、メインのコンテナ内で docker コマンドの実行を許すと、いわゆる Docker in Docker のセキュリティ問題に直面するためこのような構成になっていると思われます。
なので、image に使用するイメージは、docker コマンドとチェックアウトのための git コマンドがあるものが望ましいと考えられます。幸いなことに、公式の Docker イメージ に git 入りのイメージ（*-git でタグが付いてるイメージ）が存在するので、それを使うのが楽です。
特定のタグのみでビルドが実行されるようにするためには、CircleCI の Workflow の機能を使う必要があります。
上記の公式ドキュメントに書いてありますが、タグのみでビルドが実行されるようにするための条件は少し複雑です。CircleCI 2.0 はデフォルトですべてのブランチでビルドが実行され、タグでは実行されないようになっています。なので、上記の例のように、すべてのブランチを ignore して、ビルドされてほしいタグ名を正規表現で記述するという2つの設定が必要になります。
まとめ
CircleCI 2.0 で Docker イメージをビルドして Docker Hub に push する方法と、それを特定のタグでのみ実行されるようにする方法について記述しました。
もう少し実用化を考えるとイメージのキャッシュを行って高速化したいところですが、ちょっと複雑になりそうなのでまたいつか気が向いたら書くことにします。
