Githubが無料アカウントでもプライベートリポジトリを無制限に作れるようになったという情報を受けまして、2015年から$7払い続けていた私のアカウントを無料に戻してみました。以下、手順です。 ...

はじめに 巷にはDangerというPull Requestのチェックを自動化するツールがありまして、自分のプロジェクトにも導入してみたいなと考えています。ただ、このDangerをCircleCI上で実行するにはちょっとした問題があるようです。 ...

はじめに HerokuにはHeroku Container Registry & RuntimeというHerokuでDockerベースのアプリケーションを実行できる非常に便利なサービスがあります。さらに便利なことにdynoのタイプ(web, workerなど)ごとに異なるimageをプッシュできるのです。 が、たとえばweb dynoとHeroku Scheduler経由で実行するscheduler dynoのimageを分けることってできるのか？ という疑問がわいてきたので調べてみました。 ...

単一のjobかworkflowsを使うかでやり方が異なります。 単一のjobの場合 branchesを使います。 masterブランチでのみ処理を実行したい場合の例: version: 2 jobs: build: docker: - image: circleci/ruby:2.5.0 branches: only: - master steps: - run: command: echo "This job runs on only master branch" この機能、ローカル環境では機能していないように見えます。onlyのところをmasterにしてもdevelopにしてもjobが成功したので。 Circle CI上で走らせるとskippedになっているので問題はなさそうです。 ...

ステップが失敗しても次のステップを実行したい Circle CI 1.0とは異なり、2.0ではステップが失敗すると次のステップは実行されません。 ちなみにコマンドの戻り値が0以外であれば失敗となります。 ...

dockerのuserattributeを使います。 例: version: 2 jobs: build: docker: - image: circleci/ruby:2.5.0-node-browsers user: root steps: - run: command: whoami 結果: #!/bin/bash -eo pipefail whoami root 例のcircleci/rubyのデフォルトのuserはcircleciになっていますが、上記のようにuserを上書きすればユーザーをrootに変更できます。おそらくdocker runの--userオプション相当なのだと思います。 ...

たとえば下記のような感じでCircleCIのビルド番号を参照して新たに環境変数をenvironmentセクションの中で定義しようとしても期待したとおり（c5f3e6619f3637af832c862918ad6e896d87b85d.zipみたいな）にはなりません。 ...

workflowを利用して、build jobで作成した成果物をdeploy jobで特定の場所にリリースしたいことはよくあると思います。 Circle CI 2.0ではjobごとに異なるDockerコンテナが起動するので、別のjobにファイルを受け渡すにはpersist_to_workspaceを使います。 一方、そのファイルを参照するjobではattach_workspaceを使います。 実際にやってみます。以下、config.yml version: 2 jobs: build: docker: - image: circleci/ruby:2.5.0-node-browsers steps: - run: mkdir -p /tmp/workspace - run: echo 'This is artifact' >> /tmp/workspace/artifact.txt - run: cat /tmp/workspace/artifact.txt - persist_to_workspace: root: /tmp/workspace paths: - artifact.txt deploy: docker: - image: circleci/ruby:2.5.0-node-browsers steps: - attach_workspace: at: /tmp/workspace - run: cat /tmp/workspace/artifact.txt workflows: version: 2 build-deploy: jobs: - build - deploy: requires: - build workflowはローカルでは試せないのでリモートで実行します。 ...

はじめに 訳あってとあるHeroku上のRailsアプリで使っているDBをHeroku PostgresからGoogle Cloud SQLにしようと思ったのですが、DATABASE_URLを書き換えようとしたらCannot Overwrite Attachment Values DATABASE_URLと言われてしまいました。 ...

はじめに Herokuで実際にアプリケーションを運用していると機能の追加に伴って環境変数を追加したり、アドオンを追加したりすることがあると思います。 そして、これらは手作業で行うことが多いです。ごく少人数で開発しているときはそれでもなんとかなるのですが、開発者が増えたり、開発者のレベルにばらつきが出てくるとコードで管理してリリースする前にレビューを行いたいと思うようになってきました。 現在developer previewで公開されているheroku.ymlというマニフェストファイル的な機能がゆくゆくはそういうものになっていってほしいなあと個人的に考えているのですが、現状はどちらかというとアプリケーションのbuildをシンプルに記述できるようにするのが目的のようなので、本番環境で参照する環境変数を管理したり、アドオンを管理したりする機能はありません。となると、現状で私のニーズを満たしてくれる最有力候補はTerraformになりそうです。 前置きが長くなりましたが、Terraformを試してみたいと思います。 ...