CircleCI

個人で Slack workspace を作るのはオーバースペックだという宗教的な理由から、各種通知は Pushover という通知サービスを利用しています。[2015-03-08-1] に紹介記事を書いてましたね。 今は亡き im.kayac.com を便利にしたやつと言えば、分かる人には分かるでしょうか？ 長らく CI の失敗通知は CircleCI のコンソールを見て久しぶりに気づくという、ダメな運用をしていました。去年の 9 /13 に重い腰を上げて、CI が失敗したら Pushover に通知させようとしました。その時作った PR がこちらです。 https://github.com/pbrisbin/pushover-orb/pull/1 レビューして頂いたは良いが、放置してしまい、修正 commit をしたのが先日の 1/18。無事マージされましたが、作者様は GitHub Actions に移行しており、メンテナーにならないかとお誘いを受けました。 https://github.com/pbrisbin/pushover-orb/pull/1#issuecomment-762920348 ちょうど tfupdate orb で CircleCI Orb の勘所は掴んでいたので、喜んで承諾。リリース周りを整えたリポジトリがこちらです。 メンテナーも変わったことだし、メジャーバージョンアップしつつ v2.0.0 をリリースしました。 https://circleci.com/developer/orbs/orb/masutaka/pushover?version=2.0.0 https://github.com/masutaka/pushover-orb/releases/tag/v2.0.0 よろしければご利用くださいませ。

[2019-12-20-1] で circleci/orb-tools を解説しました。リリースフローがよく出来ていたので、感動した記憶があります。 しかし、記事を書いた時にはすでに v9.0.0 がリリースされており、それはそれは大きな BREAKING CHANGES でした…。 やる気が出なかったので、tfupdate orb で使っているバージョンはずっと据え置いていましたが、今日急にやる気になったので、最新の v10.0.3 にアップデートしました。 当該 PR はこちらです。.circleci/config.yml がかなり短くなりました。 https://github.com/masutaka/circleci-tfupdate-orb/pull/2 公式ドキュメント や circleci/orb-tools のドキュメント はありますが、よく分からないのと、今までの経緯からあまり信用できないので、v10.0.3 のコードリーディング をして理解しました。 circleci/orb-tools 自身の .circleci/config.yml も読みました。結果的にここまで複雑にする必要はなかったです。 https://github.com/CircleCI-Public/orb-tools-orb/blob/v10.0.3/.circleci/config.yml 今までは master ブランチに commit するたびに orb のバージョンが自動的に上がっていきました。セマンティックバージョンの制御はできません。 現在はその commit message によって、orb バージョンを半自動的に上げられるようになりました。セマンティックバージョンを制御可能です。 v8.27.5 での振る舞い master ブランチに commit が追加された時、src/commands または src/jobs 以下が変更されていれば minor version が、それ以外の変更では patch version が自動的に上がりました。major version はサポートされていませんでした。 何も考えずに済んだので楽ではありましたが、制御できないのは不満があったのかもしれません。 v10.0.3 での振る舞い master ブランチに commit が追加された時、当該 commit message に以下の文字列が含まれていれば（例 ）、その指定に従ってバージョンが上がります。...

今年の春くらいに CircleCI の UI が新しくなったタイミングで、各プロジェクトで設定した Slack 通知用の設定ページはどこかにいってしまいました。 こんな画面でした。 各プロジェクトの設定ページによると、現在は Slack orb を使う必要があるそう。 例: https://app.circleci.com/settings/project/github/masutaka/example/slack それはまあ移行すれば良いのですが、旧 UI で設定した Slack の Webhook URL を確認したくても出来ません。Slack orb に移行した場合に、旧 UI で設定した通知を無効にしてくれるのかも気になります。 CircleCI のサポートに聞いたところ、残念ながらそのような UI は用意されておらず、Slack orb に移行しても自動的な無効化はしてくれないそう。 マジすか・・・！ Undocumented API を使って無効化が必要とのこと。新 UI では確認も変更も削除もできないとのこと。それはさすがに困る人が多いんじゃないかなあ…？全部サポート対応するのかしら。 それはそれとして、この記事ではその Undocumented API を使って、旧 UI で設定した Slack Integration の確認と変更、削除のやり方をまとめます。説明しませんが、IRC も出来ると思います。 ※ 9 月にサポートに聞いた時、「Undocumented API を使うのは構わないのだけど、やり方自体も Undocumented なのは変なのでヘルプページに書いて欲しい」と伝えたけど、書かれてないようなのでこの記事を書いています。 確認する こんな感じです。CIRCLE_TOKEN は https://app.circleci.com/settings/user/tokens で作ります。 CIRCLE_TOKEN=xxxxxx VCS=gh ORG=masutaka PROJECT=example curl "https://circleci.com/api/v1.1/project/${VCS}/${ORG}/${PROJECT}/settings" \ -X GET \ -H 'Content-Type: application/json; charset=utf-8' \ -H "Circle-Token: $CIRCLE_TOKEN" \ | jq '{ vcs_url: ....

今回 pbrisbin/pushover orb を変更した。PR を送る前に、動作確認がてらしばらく使っている。今後のためにやり方を残しておく。 動作確認用の orb を publish するために masutaka/pushover という scope を作る。orb の scope は一度作ったら削除できず、リネームしか出来ないようだ。自分用なので気にしないことにする。 $ circleci orb create masutaka/pushover You are creating an orb called "masutaka/pushover". You will not be able to change the name of this orb. If you change your mind about the name, you will have to create a new orb with the new name. ✔ Are you sure you wish to create the orb: `masutaka/pushover`: y Orb `masutaka/pushover` created....

⚠️ circleci/orb-tools v8.27.6 を使っています。さっき見たら v9.0.0 がリリースされており、trigger-integration-workflow 等のジョブ名が変わり、互換性がなくなったことは確認しました。 先日、tfupdate の CircleCI Orb を作りました。 tfupdate とは tfupdate は terraform のアップデートを支援してくれるツールです。ローカルの .tf ファイルに書かれた、terraform と terraform provider のバージョンを最新にしてくれます。 .circleci/config.yml に組み込むと、定期的に pull request を作ってくれます。 例: https://github.com/minamijoyo/tfupdate-circleci-example/blob/cd8e5561b7eabb25aa3cd024dfcf5b868c4bda45/.circleci/config.yml タイムリーなことに、作者の minamijoyo さんが書かれた記事があります。詳しくはこちらをどうぞ。 tfupdateでTerraform本体/プロバイダ/モジュールのバージョンアップを自動化する - Qiita なぜ circleci-tfupdate-orb を作ったのか 前述の .circleci/config.yml を見ると分かりますが、かなり行数が長いです。130 行あります。 tfupdate 以外にも CI の設定はありますし、これを各リポジトリに書くのは辛いです。そのため、ほぼそのまま Orb にしたのが v0.0.2 です。 https://github.com/masutaka/circleci-tfupdate-orb/tree/v0.0.2 CircleCI Orb Registry はこちらです。v0.0.2 は circleci CLI を使って手動で Publish しました。Publishing Orbs や他の記事など、読み漁りました。 https://circleci.com/orbs/registry/orb/masutaka/tfupdate?version=0.0.2 なぜ circleci/orb-tools を使ったのか 変更を加えるたびに Orb Registry に publish していくのはなかなか面倒です。...

このブログは GitHub で管理しており、master に commit が追加される と、CircleCI が capistrano を使ってデプロイします。 [2017-04-13-1] でテストを CircleCI 2.0 で動かしたので、デプロイも 試してみました。 最終的な circle.yml とデプロイスクリプトはこちらになりました。 基本的に “add_ssh_keys” と “deploy” step 以外は [2017-04-13-1] と 同じです。ハマりそうなところだけ記載していきます。 ハマりそうなところ Deployments - CircleCI のとおり、“deploy” step があればデプロイ出来ます。 ただ capistrano で GitHub の private repository をデプロイする場合、 最低 2 つは SSH Key が必要になると思います。 (1) 本番サーバ（masutaka.net）への SSH ログイン (2) SSH ログイン後に GitHub に SSH アクセス これらの設定方法を説明していきます。 デバッグは CircleCI の各ジョブの Rebuild with SSH から、実際に本番 サーバに ssh ログインできるか確認していくと、分かりやすいと思います。...

先日の [2017-04-13-1] で気になったので調べてみました。 初めに結論から。 circleci コマンド（シェルスクリプト。macOS 等で実行可能） └ docker run circleci/picard └ /usr/bin/circleci (https://github.com/circleci/build-agent ) ・circleci コマンドは build-agent というコマンドを Dockerize した シェルスクリプト。 ・build-agent は golang 製のツールで、/usr/bin/circleci としてコン テナ内に存在する。おそらく private repository https://github.com/circleci/build-agent で開発されている。 ・Docker Image は https://hub.docker.com/r/circleci/picard/ だが、 Dockerfile は公開されていない。Alpine Linux ベースのようだ。 ・この Docker Image には docker コマンドは存在しない。 /usr/bin/circleci が Docker Hub の API を使って、docker pull 相当 のことなどを実行するようだ。 調査過程や詳細など Running Jobs Locally - CircleCI に書いてある方法で https://circle-downloads.s3.amazonaws.com/releases/build_agent_wrapper/circleci が /usr/local/bin にインストールされる。 これは circleci/picard を docker run するだけのラッパーシェルスク...

先日素振りがてら、個人の小さな Rails リポジトリを Dockerize しました。 https://github.com/masutaka/github-organization-watcher/pull/45 現在クローズドβの CircleCI 2.0 は Docker 前提らしいので、これも素 振りがてら移行してみました。 https://github.com/masutaka/github-organization-watcher/pull/48 CircleCI 2.0 はここから申請すれば、すぐ使えるようです。 https://circleci.com/beta-access/#request-access 移行前の印象 (1) 1.0 では宜しくやってくれたけど、2.0 は circle.yml に全部書く必 要があるみたい。面倒そう。 (2) とは言え、Dockerfile や docker-compose.yml があるし、ちょっと やれば動くだろう。 (3) Alpine Linux の Docker Image 使えば、1.0 よりは速くなるのかな。 移行後の感想 (1) 予想に違わない面倒くささ・・・！ オートマがマニュアルになった感じ。 (2) 使えませんでした ／(^o^)＼ 参考にはなったけど。 (3) 速い・・・！！！（移行前: 01:38 、移行後: 00:30 ） 両方ともキャッシュあり状態です。Alpine Linux もそうかもしれないけ ど、とにかくキャッシュのリストアが速かったです（後述）。あと、 CircleCI のビルドが全体的に高速です。 circle.yml circle.yml は 1.0 から 2.0 に移行して、このようになりました。同じ ディレクトリにある Dockerfile や docker-compose....

サーバの CI ってどうするのが良いのでしょうね。現状やむを得ず行って いますが、やり過ぎ感も否めないです。 [2014-09-14-1] に Wercker+Vagrant+EC2 の組み合わせでこのサーバの CI を始めてから、[2015-02-08-2] に CircleCI+Vagrant+EC2 に変更しま した。そして今回、CircleCI+Docker に変更しました。 理由は EC2 を使うのは大げさだと思い始めたからです。CI 時間の短縮を 期待しましたが、ほとんど変わりませんでした。結果的に、時々 EC2 イ ンスタンスを起動するのに 30 分以上かかり、CircleCI のタイムアウト 時間を超える問題は解決出来ましたが。 Docker 入門できて自己満足は得られたのですが、Docker の使い方ではな いなあというのが正直な感想です。 Docker を使ってサーバの CI をするためには、openssh-server をインス トールする必要があります。そもそも Docker は一度インスタンスを作っ たら変更を加えるべきではないため、Docker を起動してから knife-solo で変更を加えるのは誤った使い方です。 このブログのサーバ（さくらの VPS）には nginx や td-agent、 elasticsearch などがごちゃごちゃと入ってますが、同じ環境を Docker で作るのもおかしな話です。Docker は 1 サーバ 1 責務だと思うので、 例えば nginx だけをインストールする使い方が正しい気がします。 そういう意味で無理して CI しているなあと、モヤモヤしているところです。 修正内容はこちらです。末尾に解説を記載しました。 ./script/bootstrap-docker.sh このスクリプトは CircleCI の dependencies.pre で実行されます。...

俺得な保存版記事です。設定するたびにやり方を思い出すのが面倒になり。 1. CircleCI の設定 GitHub の Personal access tokens のページで token を作成し、 CircleCI の Project Setting -> Environment variables に GITHUB_ACCESS_TOKEN という名前で追加します。 CircleCI の URL は以下になります。 https://circleci.com/gh/{ユーザ名}/{リポジトリ名}/edit#env-vars 2. circle.yml の変更 このように circle.yml の deployment section を変更します。 https://github.com/masutaka/masutaka-29hours/commit/0ba9ef03348568baaa5cf271d4f6e41305f8fdfe 環境変数 BUNDLE_UPDATE が指定されていたら、 circleci-bundle-update-pr gem をインストールして、同コマンドを実行 しています。この環境変数は後述するトリガーが設定してきます。 circleci-bundle-update-pr コマンドでは以下が実行されます。 bundle update を実行する Gemfile.lock に差分があれば、git commit し、GitHub のリモートブランチに git push する GitHub の Pull Request を作成する アップデートした Gem の差分へのリンクをコメントとして POST する bundler もアップデートしているのは、1.10.0 から Gemfile....