[8] CircleCI は、 CI サービス (Webアプリケーション) です。
[25] Linux と Mac OS X に対応しています。
[50]
CircleCI
で動作中かどうか判定するために、
環境変数の
CI
や
CIRCLECI
を使えます。
>>49
[82] 同じプロジェクトの他のリポジトリーの環境変数はコピーしてくることができます。 他のプロジェクトからはコピーできません (地味に不便)。
[83] 環境変数は秘密の値を保存する用という扱いらしく、 設定画面でも値の一部だけが表示され、それ以外は隠されて見えません。 同じプロジェクトの他のリポジトリーにコピーだけができて、 変数の値は見れないし変数名の変更もできないので、 一度登録したら削除以外は何もできないものと思った方がいいです。
[9] 1. リポジトリーを追加する
[10] 2. 設定 → 「Heroku Deployment」 → 「Step 2: Associate a Heroku SSH key with your account」
[11] 3. Makefile に Heroku 用の書き換えを追加 (一例):
create-commit-for-heroku: git config --global user.email "dummy@test" git config --global user.name "dummy" git remote rm origin rm -fr deps/pmtar/.git deps/pmpp/.git modules/*/.git git add -f deps/pmtar/* #deps/pmpp/* #rm -fr ./t_deps/modules #git rm -r t_deps/modules git rm .gitmodules git rm modules/* --cached git add -f modules/*/* git commit -m "for heroku"
[13] 4. circle.yml (一例):
dependencies:
override:
- make deps
test:
override:
- make test
deployment:
heroku:
branch: master
commands:
- "[[ ! -s \"$(git rev-parse --git-dir)/shallow\" ]] || git fetch --unshallow"
- make create-commit-for-heroku
- git push git@heroku.com:HEROKUAPPNAME.git +`git rev-parse HEAD`:refs/heads/masterdeployment: の部分がポイント。他は何でも良い。[59] この機能いつの間にかなくなった。リポジトリーごとに設定が必要ですんごい面倒なんだけど>_<
[93] ユーザー設定とプロジェクト設定の両方に API キーの画面があります。 特定のプロジェクトでだけ API を使いたいからプロジェクトの方の API キーでいいかというと、 そうでもなくて、そういうときはユーザー設定の方の API を使わないとプロジェクトが見つからないとエラーになるだけです。
[94] 2.0 になった頃から、こういう似たような設定があちこちにできて正しい方をうまく選ばないと思ったとおりに動作しない、あんまり親切に誘導してくれない、っていうケースが増えた気がしませんか。
[16] CircleCI API v1.1 Reference - CircleCI () https://circleci.com/docs/api/v1-reference/#new-build
[103] CircleCI API, , https://circleci.com/docs/api/v2/index.html#operation/triggerPipeline
[104] 実行例
$ curl -X POST https://circleci.com/api/v2/project/gh/org/repo/pipeline?circle-token=token \
--header 'content-type:application/json' \
--data '{"branch":"branch"}'[34] ジョブのスケジューリング (ビルド用の cron) – CircleCI Japanese Support Center () https://support.circleci.com/hc/ja/articles/115015481128-%E3%82%B8%E3%83%A7%E3%83%96%E3%81%AE%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0-%E3%83%93%E3%83%AB%E3%83%89%E7%94%A8%E3%81%AE-cron-
[36] 他の cron っぽいものの実装と同じく、指定時刻に正確に実行されることはまずありません。 時間帯にもよるのかもしれませんが、 まず数分は遅れて開始されます。 (もしかすると有料のほうが優先的に実行されたりするのかもしれませんが。)
machine の VM を指定する[52] 以前はデフォルトが勝手に最新の環境になっていたはずですが、 いつからかとても古い環境に固定されていて、 新しい環境にしたいなら自分で VM を指定しなければならなくなったようです。
[53]
「最新」と指定する方法が用意されていないので、
更新版が出るたびに、都度手動で書き換えないとならず、
不便です。
(古いのを使っていると、
ある日突然
apt-get
できなくなったり、
突然
pip
できなくなったりします。取得の URL が変わったり、
証明書が変わったりする変化に追いつけなくなるからです。)
"machine" : {
"image": "ubuntu-2004:202008-01" // これを都度書き換えること
},[61] context は workflow 内の job ごとに指定できます。 (build の step 単位では指定できません。)
[62] 指定した context が organization に登録されていないときは、 その job がエラーになって実行されません。
[55] CircleCI は一度盛大な非互換変更をやらかした前科があります。 仕様が完全変更されて、 修正しなければ何1つ動作しなくなるという凶悪なタイプでした。
[56] 次にいつ繰り返されないとも限りませんから、 継続して運用していくシステムに使うのは避けた方が無難かもしれません。
[30] CircleCI 1.0 End of Life on August 31, 2018 () https://circleci.com/blog/sunsetting-1-0/
[31] Sunsetting CircleCI 1.0 - CircleCI () https://circleci.com/sunset1-0/
[32] 実行環境を新しくするのは大変結構。しかしなぜ利用者に完全非互換な変更を強要するのか。 古い設定ファイルも自動変換して実行するが動作結果は保証されない、 くらいの緩やかな移行計画を立てられないものか。 突然期限を区切ってこういうことを言ってくるから、クラウド事業者は信用できない。
[33] 設定ファイルも UI も、 2.0 になって面倒になったなあ。 1.0 より柔軟性は上がっているのだけど、 1.0 では簡単にできたことが複雑になっている。ほとんどの用途において改悪でしかないと思うんだが。
[37] どんどん UI が複雑で理解不能になっていくなあ。今思い返すと 1.0 の頃が一番わかりやすかった。
[38] 強制的に新 UI に切り替えられたみたい? ジョブの実行順序が日付順にならなくて変な順序になっていて、 使い物にならない。。。
[39] 実行時間の長い古いジョブより実行時間の短い新しいジョブの方が先に出てくるようになったから、 現在実行中のジョブ一覧として機能しなくなったのが原因?
[64] retry with SSH したジョブは一覧表に出てこない。 昔は出てたのに workflow の実行順にまとめて表示に変わってから出なくなった。 おかげで今どこでジョブが実行されてるのか一覧表を見てもわからないという糞仕様w
[65] 前は成功したジョブも必要あらば再実行できたのに、 今見たらできなくなってた。
[66]
昔は IRC サーバーへの通知の設定はプロジェクト設定ページ内に項目があったのが、
いつの間にか .circleci/config.yml で手作業で書かなければならなくなったようです。
(変更のお知らせは来ていない気がしますが、それとも重要、要変更と書かれていなくて見落としていたのでしょうか。)
ところが設定項目がなくなっただけで機能は残っているみたいで、 IRC サーバーへの通知はずっと動き続けています。 (だから仕様変更がいつ行われたのかすらわからないのです。) しかし設定の変更も解除もできないのです。どうしろというのでしょう。
[67] また非互換変更の通知が来たぞ、どうなってんの?
[68] 開発工程の最適化のための CI なのに、こう非互換変更ばかりで振り回されてるとむしろ開発コスト上がってるんだよなあ。
[69] やっぱ GitHub Actions に移行するのがいいんだろうなあ。
[70] なんかまた挙動変わったな?
[71] 「All」を選んでもすべてにならない (もう1回選ばないといけない) とか頭おかしい仕様変更しやがって
[95] いつのまにか yml の記述形式が更新されていて、それに合わせてドキュメントが更新されているのに、 元々の .yml ファイルに古いバージョン番号を書いているせいで思ったように動作しないことがあります。
[96] バージョン番号を更新すればいいだけのことなのですが、エラーメッセージにはバージョンが違うとは一言も出てこないし (エラーにならないこともあるし)、 ドキュメントもバージョンいくつからですとははっきり書いていないし、 例文も一部を示しているとバージョンが入っていないことがあって、 バージョンが理由だというのがわかりにくい。
[97] バージョニングの失敗でユーザーが混乱させられる典型例ですね。
[84] CircleCI Container Plan Migration Guide - Announcements - CircleCI Discuss, https://discuss.circleci.com/t/circleci-container-plan-migration-guide/42938
[85] 利用の程度によって異なりますが、数万円レベルの値上げになることもありそうです。 (長く使っているユーザーほど使い込んでそうだから、値上げ幅が高そう。)
[86] 前にメール来たときは何もしなければ Free plan (無料) に自動移行するって書いてたくせに、 今度来たメールには Performance plan (従量課金) に自動移行するって書いてるぞ、 無茶苦茶だな。
[87] >>86 前に来たメールを信じて何もしないと利用状況に応じて急に値下げになることもあれば、 急に大幅値上げになることもあり得るわけで。 消費者に一方的に不利な料金変更とも言い切れないから法的には無効な契約変更ではないのかもしれないけど、 利用者の明示的な承認を得ずにこんな変更をしてしまうのは感じが悪い。
[91] 半月以上前に解約して Free plan に移行してるのに、 プラン変更しないと Performance プランに自動移行するよメールがやってきた。 どうなってんの!?
[92] メールで案内されるプラン移行のガイドページ、 古いまま更新されてないっぽくて、 旧プランの終了日は未定とか書いてあるのよね。 顧客対応が杜撰すぎない?
[88] Performance プランは解約しても期限まで有効みたいなことが書いてありました。 詳しくはよくわかんない。
[89] それ以前からあった container-based プランは解約するとその場で無効になります。 (公式のドキュメントを探したけど見つけられなかった。)
[90] 解約するとそれ以前は表示されていた支払履歴まで見れなくなりました。
[105] CircleCI の Docker 実行環境は何か特別らしく、 手元環境や GitHub Actions では普通に動作する単純な Docker image の単純な操作でも Circle CI ではなんだかよくわからない謎エラーが出ることがしばしば。
[106] なんとか Circle CI の実行環境の影響だとまで突き止めても、解決方法がわからないことが多すぎて...
[107] 昔からずっとなおらないし、 Docker image 側の OS を新しくするほど悪化するし、 多分今後悪化することはあっても良くはならなそうだよなあ。。。
[22] 最低$19/月。
まだ試していないが Travis CI や Wercker と違って heroku コマンドを直接使えそう。
IRC 通知はあるが、失敗・復活が privmsg でそれ以外が notice という使い分けができない。(他の CI でもできないが。)
管理権限がないリポジトリは読み書き権限があっても登録できない。気づいたら勝手に fork していて(?)罠っぽい。
横に長い画面想定で作られていて使いにくい。特に設定ページ。それと一部フォームコントロールが奇抜なのを除けば今風の UI だけど悪くはない。
試用では 6 containers 利用できるが、一番安いプランでは 1 container しかない。二番目に安いプランでも 6 はない。
課金は user/organization 単位なので、自分のリポジトリと組織のリポジトリ両方で試したりすると両方の試用カウンターが勝手にスタートしてしまってもったいないw 罠としか思えないwww
deploy フェーズの排他制御みたいなのは特にないので、複数コミットのデプロイが同時動作することがある。
[1] Continuous Integration and Deployment on CircleCI just got better: now it’s free. | The Circle Blog ( ( 版)) http://blog.circleci.com/continuous-integration-and-deployment-on-circleci-just-got-better-now-its-free/
[5] 基本機能は無料化されました。
[2] GitHub に対応している。
BitBucket には対応していない。 その後対応しました。
[3] 公開リポジトリーの実行結果は公開される。
[6] 昔から UI は微妙ですが、同種サービス内ではましな方です。 昔より少しは改善されています。使っていれば慣れるというのもあります。
[7] 同種他サービスとは違って、やりたい操作がどこにあるのか想像付かないということはない。
[15] CircleCI API Documentation - CircleCI () https://circleci.com/docs/api/
[17] Clearing the source cache? - Build Environment - CircleCI Community Discussion ( (著, )) https://discuss.circleci.com/t/clearing-the-source-cache/2771/14
[18] Git のタグや submodule の URL の変更など、一部の変更はキャッシュされてしまい、 反映されません。 現時点で UI から消去する方法がなく、サポートに問い合わせるしかないようです。
[19] Pricing and Plan Information - CircleCI () https://circleci.com/pricing/
[20] Continuous Deployment with Heroku - CircleCI () https://circleci.com/docs/1.0/continuous-deployment-with-heroku/
[21] Configuring CircleCI - CircleCI () https://circleci.com/docs/1.0/configuration/
[23] GitHub organization に対応する CircleCI 側の管理権限は、 GitHub 側で管理者になっているユーザーに与えられます。
[24] 請求情報は Web API https://circleci.com/api/v1.1/organization/hub/{org}/invoices から取得できます。管理権限のあるユーザーのアクセストークンがあれば取得できます。
[26] workflow 微妙だなー。複雑で使いにくい。
[27] Caching Docker images in Workflows - CircleCI 2.0 - CircleCI Community Discussion () https://discuss.circleci.com/t/caching-docker-images-in-workflows/16507/2
[28] Parameterized Builds - CircleCI () https://circleci.com/docs/1.0/parameterized-builds/
[29] Running Jobs With the API - CircleCI () https://circleci.com/docs/2.0/api-job-trigger/
[35] 設定ファイルが間違っていると、 Jobs のリストを見ても何も実行されていなくエラーに気づかないことがある。 Workflows を見るとエラーが出ていたりする。 (とてもわかりにくい。)
[40] Pipeline は実行中なのに Workflow は未実行になっていたり (何も動いていないことになってる)、 表示が怪しいことが多い。 システムを必要以上に複雑化したから、 おかしな不具合が出まくるようになったんやで。
[41] Pipeline はジョブが追加されてすぐに実行中に変わるから、 実行時間 = ジョブ追加からの時間で、 実際に何かを実行してる時間ではない。 実際になにかするのは Workflow のほうだけれども、 そちらの実行時間は表示されないから、 その待ち時間は何もしていないのに延々実行時間だけが進んでいく虚無になる。 本当の実行時間は個別に奥深くのページを開いていかないとわからない。
[42] そんなわけなので「RUNNING」の表示は本当の実行中と、何もしていない待機中を含んでいるのがとてもわかりにくい。 昔は待機中は別の表示だったんだが。
[43] そろそろ GitHub Actions への移行も検討していいのでは?
[44] 前は実行中 (未完了) のジョブでも再実行 (ジョブをコピー) できたのに、 今はできなくなった。 失敗が確定して後処理中 (まだ実行完了していない) に再実行予約できなくなって不便だ。
[45] どれが実行中でどれが未実行かさっぱりわからなくて草
[46] 実行完了前のジョブを再試行したいときは、 キャンセルしたら再試行ボタンが有効になるので推し放題という裏技w 一度実行開始されてしまうとキャンセルしづらくなる (その時点で中断されてしまうし、 artifacts にアクセスできなくなってしまう) ので、実行開始前に中止して再試行しておくべきというバッドノウハウもいいところ。
[47] Parallel job のいくつかが失敗、いくつかが成功、いくつかが実行中のとき、 失敗したものしか表示されなくなった。以前は実行中のものも表示されていたはず。 わかりにくくなった。
[48] retry しても最初のジョブが登録された順のままだから、 一覧表を見てもどれが最近完了したもので、 どれが昔のものか、さっぱりわからん。
[54]
Workflow 中の job のいくつかを、他のいくつかより先に実行させたいとき、
requires で完了を待たせることはできるが、
実行開始だけを待たせる方法がない。
書いた順番に実行されるのかと思いきや、
後の方が先に実行されることがある。
(例えばテスト完了を待たずにデプロイをしたいので、両者を同時に実行できる余裕があれば同時に、
実行環境が埋まっていればデプロイを先に実行させたいのに、
テストが実行環境を埋めてしまうことがある。)
[57] 昔は他のprojectから1個ずつ環境変数のインポートできたよね?? なんか全部一括インポートしかできなくなってて不便なんですけど。。。
[58] いつも必要な機能だけピンポイントで消し去ってて草
[72] 最近営業メールがうざい、まだこれ以上金払えって?
[73] ログの見てると何もしてないのに勝手にスクロールするし (テスト完了してるから最新の情報が追加されたわけでもない)、 ログの途中をクリックしても勝手に末尾にスクロールするし、 本当に意味不明すぎる・・・。
しかもこの意味不明な挙動になってもう何ヶ月も放置されていて、 修正する気はないのかわざとこういう仕様になっているらしい、まったく理解不能。 開発者自身はこのサービスを使っていないのかも?
[76] SSH有効で実行するとログの先頭に接続先の情報が出てくるけど、ログの末尾にどんどん情報(?)が追記されていくから、接続先をコピペしようと上にスクロールすると勝手に末尾にスクロールされるし、コピペのため選択しようとクリックしても末尾にスクロールされる、って地獄が待ってるんだぜ。このサービス設計したやつ狂気じみてるだろ?
[74] 完了予想時間が出るようになったのは便利。珍しく良い変更。
しかし出るときと出ないときがあって、出現条件が不明瞭なバグ(?)はいただけない。
[75] 一覧画面が最新の情報に更新されるときと、数時間前の情報が表示されたままかわらないときがあるのも、わけわかんないのよね。 動作に一貫性がなくて困る。
[77] 令和4年1月末くらいの変更 (status に不具合告知が載ってた & Twitter にも被害報告が投稿されてたやつ) のあと実行時間が倍くらいに増えてるんですけど・・・なんでやねん
[78] 単体でのビルド時間はあまり変わっていないのだけれども、 Docker 関係のオーバーヘッドが増えてるのかな? 障害もその辺をいじってる感じの症状だったし。
[79] なんかどんどんおかしくなってくなあ。 (ユーザーにとっては) 「何もしてないのに壊れた」がこのサービスには多すぎて辛い。
[80] ビルド時間が伸びるのって、従量課金にとっては深刻な問題では... まさかわざとやってるとは思わんけど、 同じコード動かしてるのに時間が倍かかって課金が倍請求されるとしたら大問題では?
[81] いつぞやの UI 変更以来、タイミングによっては個別ページから再実行はできるのに、 一覧ページは再実行できなくて不便になったよね。
[98] ログの行の横にコピーボタン出てきたから行をコピーできるのか、便利だなと思って押してみたら行へのリンクがコピーできるだけで草
[99] 同じ workflow 内の job の同時実行するしないはある程度制御できるみたいだけど、 違う workflow の実行の排他制御はできないみたい。だから同じプロジェクトで最大1個しか走らせない、 みたいなのができない。 (プライベートリポジトリーだと最大実行数制限があるから、逆にこれができてる? (アカウント(?)単位になっちゃうけど。))
CIはいろいろな CI サービスで使われています。