CircleCI で cimg/ruby:3.* のイメージには php も python も webrick も node も入っていない - 約束の地
結論 公式ドキュメントは以下。 circleci.com gyazo.com なぜこれを気にしたのか monorepo っぽい構成になっているプロダクトにおいて、静的な Webページ のテストを走らせるためにワンライナーの Webサーバ を立ち上げようとしたから。 $ php -S や $ python -m http.server が立ち上がらないのはもちろん、$ ruby -run -e httpd もダメだったので驚いた（cimg/ruby:3.* のイメージには webrick が入っていないから）。 PHP や Python を入れていると CI に時間がかかりすぎるので、素直に $ gem install webrick してから Ruby で Webサーバ を起ち上げることで解決…しなかった。 対話シェルでは問題ないが、RSpec 内でシェルコマンドを実行すると立ち上がらない
Debian/Ubuntu ベースのイメージを用いて CircleCI で Yarn をインストールするときにはいきなり sudo apt-get install yarn してはだめ - 約束の地
結論（どうするか） Yarnのパッケージを明示的に指定して、sudo apt-get install -y yarn をしましょう。-run の部分だけを書くと次のとおりです。 - run: name: Install Yarn command: | curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add - echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list sudo apt-get update sudo apt-get install -y yarn だめな場合 sudo apt-get install -y yarn をして、which yarn をして、y
CircleCI で cron を設定する方法 - 約束の地
公式ドキュメント CircleCI は公式ドキュメントが充実していますので、一読しましょう*1。 circleci.com YAML の例 cron を実行するための最低限に近い .circleci/config.yml の例は次のとおりです。 version: 2 jobs: build: docker: - image: circleci/node:13.5.0 working_directory: ~/repo steps: - checkout - run: name: Hello, CircleCI cron World command: | echo 'Hello, CircleCI cron World!' workflows: version: 2 lets_execute_cron: triggers: - schedule: cron: '10 09 * * *' fi
CircleCI CLI で実行されるジョブの名前は "build" でなければいけない - 約束の地
注釈 2021/02/23 現在の情報です。 結論 build という名前のジョブが存在しない場合、以下のようなエラーが出ます。 $ circleci local execute Docker image digest: sha256:99018c7b8dca0f952d65d80bfe6174a8ea0ca0e1908974cfea053e4be170eee5 ====>> Spin up environment Build-agent version () Error: Configuration errors: 1 error occurred: * Cannot find a job named `build` to run in the `jobs:` section of your configuration file. If you expected a workflow t
CircleCI の "store_artifacts" における "destination" を使う場合と使わない場合の違い - 約束の地
公式ドキュメントより 公式ドキュメント には、以下のように記載されています。 現在、store_artifacts には path と destination の 2 つのキーがあります。 path は、アーティファクトとしてアップロードされるファイルまたはディレクトリのパスです。 destination (オプション) は、アーティファクト API でアーティファクト パスに追加されるプレフィックスです。 path で指定されたファイルのディレクトリがデフォルトとして使用されます。 YAML の例 steps に以下のような YAML が設定されているとします。公式ドキュメントの内容そのままです。以降はこの YAML を用いているものとして説明をします。 steps: - run: name: ダミー アーティファクトの作成 command: | echo "my artifact fi
CircleCI で Rails の db:create に失敗するときの対処法 - 約束の地
前提条件 以下のような環境です。 Ruby のイメージは circleci/ruby:3.0.2 データベースは PostgreSQL エラーメッセージ 以下のようなエラーメッセージが出ます。 #!/bin/bash -eo pipefail bundle exec rails db:create rails aborted! LoadError: libffi.so.6: cannot open shared object file: No such file or directory - /home/circleci/repo/vendor/bundle/ruby/3.0.0/gems/ffi-1.15.3/lib/ffi_c.so /home/circleci/repo/vendor/bundle/ruby/3.0.0/gems/bootsnap-1.8.1/lib/bootsnap
CircleCI の steps 内で条件分岐をする方法 - 約束の地
結論 when を使います。run: の step 内のシェルスクリプトで分岐する方法はよく見るのですが、step そのものを分岐します。 circleci.com 使い方具体例 公式ドキュメントに書いてあるとおりです。steps: 配下に when: を書き、その配下に condition: を書き、そしてその配下に条件分岐を書きます。条件を満たした場合、その when: の内容が実行されます。 condition: を記述するか否かについては注意が必要です。公式ドキュメントにあるように、jobs: 配下の記述においては condition: の表記が必要になります。 一方で workflows: 配下の記述に置いては不要となります。 Note: When using logic statements at the workflow level, do not include the c
CircleCI の Workflow で依存関係を requires で指定する際の名称は name: の設定でなければいけない - 約束の地
結論 具体例を見たほうが早いと思います。 以下のような Workflow（抜粋）があり job_a -> job_b と実行したいものとします。 sample_workflow: jobs: - job_a: foo: 'bar' - job_b: requires: - job_a 上記の YAML は正しい書式です*1。 注意するケース job_a に name: が設定されている場合には注意が必要です。その際には requires: の指定名は name: の名前を指定しなければいけません。job_a という名前を指定するとエラーになります。 以下がエラーが出るケースです。 sample_workflow: jobs: - job_a: name: My Job A foo: 'bar' - job_b: requires: - job_a 以下が OK のケースです。 sample
CircleCI 内で Docker のコマンドを使いたい場合 - 約束の地
結論 steps の中で setup_remote_docker を実行（記述）した後、docker コマンドを実行します。 具体例 NG な例（setup_remote_docker を実行しない場合） setup_remote_docker を実行しないと次のようにエラーになります。 .circleci/config.yml は次のとおりとします。 version: 2.1 executors: ubuntu: docker: - image: cimg/base:stable-20.04 jobs: foobar: executor: ubuntu steps: - checkout - run: command: | docker run --rm ubuntu:20.10 /bin/echo 'Hello, World!' workflows: version: 2 hogeho
CircleCI の CLI では "matrix" キー を用いたマトリックスビルドは実行できずにエラーになる - 約束の地
前提 以下のような .circleci/config.yml ファイルがあったとします。 version: 2.1 orbs: node: circleci/node@4.1.0 jobs: my_job: docker: - image: cimg/base:stable parameters: node-version: description: Node.js のバージョン type: string default: "14.0" steps: - checkout - node/install: node-version: << parameters.node-version >> install-yarn: true - run: command: node -v workflows: my_workflow: jobs: - my_job: matrix: parameters
CircleCI の SSHデバッグ の際に Permission denied (publickey) エラーが出る場合は鍵ファイルを指定する - 約束の地
状況 SSHデバッグの際に、以下のように接続を促されたとします。 You can now SSH into this box if your SSH public key is added: $ ssh -p 55555 10.10.10.10 Use the same SSH public key that you use for your VCS-provider (e.g., GitHub). RSA key fingerprint of the host is SHA256:FOOBAR MD5:HOGE This box will stay up for 2h0m0s, or until 10m0s passes without an active SSH session. そして $ ssh -p 55555 10.10.10.10 を実行した時に以下のようなエラーになったとし
GitHub Actions と CircleCI を「ローカル環境実行」という観点で比較 - 約束の地
注意 2021/09/26 時点での情報です。 前提 GitHub Actions では act を用います gh コマンド は push されたものを手元から発動するコマンドであって、ローカル環境に存在するジョブを実行するものではないです CircleCI では 公式の CLI ツール を用います 結論 ちょっと込み入った使い方をする場合には act はつらいという印象です CircleCI には YAML のバリデータがある*1ので、それについては CircleCI が便利 act は厳密なチェックをしてくれるという意味では有用でもあるし不便でもある 例えば、特定の on: でしか使用しない {{ github.foo.bar }} を共通のジョブに組み込んでいるとき、それが定義されてないというエラーが出る 一方で act では一部の記述が誤判定？される 例えば、run: | 内で #
CircleCI で SSH する（実行コンテナの中に入る）方法 - 約束の地
結論 1. 「Rerun」メニューから「Rerun Job with SSH」を選ぶ gyazo.com 再度ジョブが実行されます。時間がかかるジョブの場合は待ちます。 2. 実行ステップの最後に「Wait for SSH sessions」と現れるので、そこの詳細を見る 以下のように SSH するアドレスとポートが表示されています。 gyazo.com 3. ログインする（鍵が必要な場合は指定する） 「2.」の SSH のコマンドを実行してログインします。表示されているメッセージにもあるように、GitHub などの鍵が必要になることがあります。 鍵が必要な場合は以下のように指定します。 $ ssh -p 12345 123.123.123.123 -i /path/to/yourkey 4. ログインが完了する プロンプトが circleci@5b0288e73563:~$ などのように
CircleCI と GitHub Actions のどちらを使うか - 約束の地
注意 2021/09/25 時点での状況に基づいています。 結論 GitHub Actions を選んでおけばまず問題ない 業務で課金前提なら CircleCI もあり プライベートリポジトリの利用形態によっては CircleCI もあり 前提 前提として、CircleCI と GitHub Actions での無料利用時間の上限は以下のとおりです。 無料利用時間上限 GitHub Actions パブリックリポジトリでは上限なし プライベートリポジトリでは月2,000分または月3,000分 単位は ユーザ や Organization *1 CircleCI パブリックやプライベートの関係はなく、一週間につき 250分 ただし以下の設定項目がリポジトリごとにあります gyazo.com 結論に至った理由 上記の前提から、業務の場合には CircleCI で課金する方を選ぶということは考え
CircleCI の (sudo) apt update で失敗する場合の対処方法 - 約束の地
現象 このようなエラーが出て失敗する場合です。 Get:1 http://security.debian.org/debian-security buster/updates InRelease [65.4 kB] Get:2 http://deb.debian.org/debian buster InRelease [122 kB] Get:3 http://deb.debian.org/debian buster-updates InRelease [51.9 kB] Reading package lists... Done N: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Version' value from '10.9' to '10.10' E: Repository 'htt
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CircleCI で Chrome や chromedriver、Firefox や Gecko を入れる際には circleci/browser-tools という Orb が便利 - 約束の地
CI（GitHub Actions や CircleCI など）で Git のタグを取得する際には git fetch --unshallow する - 約束の地
CircleCI の設定ファイルは分割することはできない (2021/09/25) - 約束の地