よくあるご質問

CircleCI のスタッフがお客様の許可を得ずにコードを見ることはありません。 お客様が問題解決のサポートを希望される際は、事前に許可を得たうえで、サポートエンジニアがコードを確認させていただく場合があります。

詳しくは CircleCI の セキュリティポリシーをご覧ください。

はい、CircleCI では Docker Executor で使用する多数の「CircleCI イメージ」を提供しています。 イメージの使用方法および全リストは、 CircleCI Developer Hub および CircleCI イメージのガイドをご覧ください。

machine Executor については、 利用可能なマシンイメージをご覧ください。

実行環境やイメージに関する概要は、 実行環境をご覧ください。

はい、 Ideas のページから新機能のリクエストや、これまでにリクエストされた機能の閲覧が可能です。 新機能をリクエストするには、まず Give Feedback セクションでカテゴリーを選択します。

これまでにリクエストされた機能を閲覧する際は、Trending、Top、New で並び替えたり、下記によりフィルタリングできます。

• Under Review: CircleCI で検討中の機能リクエスト
• Planned: 今後取り組む予定の機能リクエスト
• In Progress: 現在取り組んでいる機能
• Complete: 現在のサービスに追加済みの機能リクエスト

はい、CircleCI では下記からの移行ガイドを提供しています。

• AWS
• Azure
• Buildkite
• GitHub
• GitLab
• Jenkins
• TeamCity
• Travis CI

詳細は、 移行の概要のページでもご確認いただけます。

はい、CircleCI Server は AWS または GCP 上にインストールできます。 インストールの詳細やガイドへのリンクは、 CircleCI Server v3.x の概要をご覧ください。 ご要望がございましたら お問い合わせください。

• クラウド: CircleCI のチームがサーバーの初期設定、インフラストラクチャ、セキュリティ対策を管理し、サービスのメンテナンスを担当します。 新機能や自動アップグレードが即座に反映され、システムの内部的な管理負担が軽減されます。

• サーバー: AWS や GCP などのサービスを介してご自身で CircleCI のインストールや管理を行います。 サーバーのインストールは、お客様のチームがデータセンターのポリシーに従って設定し保守を行うファイアウォールの内側にあます。 自在なカスタマイズや新バーションへのアップグレードの制御など、あらゆる管理権限がお客様にあります。

.circleci/config.yml を複数のファイルに分割する機能は今のところ提供していません。 詳細については、 サポートの記事を参照してください。

設定ファイルの分割機能は提供していませんが、CircleCI ではダイナミックコンフィグ機能を提供しています。この機能により、特定のパイプラインやパスに基づき設定ファイルを作成することができます。 詳細は、 ダイナミックコンフィグを参照して下さい。

CircleCI API v2 を使って、フォークされたリポジトリからパイプラインをトリガーし PR をビルドできます。 しかしデフォルトでは、フォークされたリポジトリからの PR をビルドしません。 この機能を有効にするには、Web アプリで Project Settings > Advanced に移動します。 詳細については、 サポートの記事を参照してください。

はい、 パイプラインのスケジュール実行が可能です。 パイプラインのスケジュール実行は、 CircleCI Web アプリで、または CircleCI API v2 を使って設定できます。

現在 ワークフローのスケジュール実行機能を使用されている場合は、 移行ガイドを参照し、ワークフローのスケジュール実行をパイプラインのスケジュール実行に更新してください。

パイプラインのスケジュール実行が実行されない場合、以下を確認してください。

• スケジュール実行化されたパイプラインに設定されている実行ユーザーは現在も組織のメンバーですか？
• スケジュールに設定されたブランチが削除されていませんか？
• お客様の VCS 組織が SAML 保護を使用してませんか？ SAML トークンは頻繁に失効します。失効している場合、リクエストが失敗します。

スケジュールの指定は、UTC 協定世界時のタイムゾーンに基づきます。

スケジュールの正確性については保証できません。 スケジュールは、設定した時間にコミットがプッシュされたとして実行されます。

同時に実行できるジョブの数は プランによって異なります。 ワークフローを使ってジョブをスケジュール化する場合、 ファンアウトとファンイン方法によりジョブの同時実行が可能です。

はい、使用できます。 サンプル設定ファイルのページで設定例をご確認ください。

リポジトリの特定の更新に基づきジョブを条件付きで実行するようにワークフローを設定できます。 これは、 条件付きワークフローと ダイナミックコンフィグを使って行います。 ダイナミックコンフィグを使うと、CircleCI の設定ファイルやパイプラインパラメーターが動的に生成され、結果の作業が同じパイプライン内で実行されます。

CircleCI アプリケーションで、各ジョブやワークフローの画面にエラーメッセージがないか確認してください。 多くの場合、.circleci/config.yml ファイルのフォーマットの誤りが原因となってエラーが発生しています。

詳細については、 YAML に関するページを参照してください。

.circleci/config.yml のフォーマットミスを確認し、それでも解決しない場合は、 CircleCI サポートセンターで検索してみてください。

お客様の組織のプランによっては同時実行に制限があり、ジョブがキューイングする場合があります。 ジョブが頻繁にキューイングする場合は、 プランのアップグレードをご検討ください。

CircleCI のすべてのお客様にシステムを安定した状態で利用していただけるよう、 リソースクラスごとに同時実行数のソフト制限が設けられています。 ジョブのキューイングが発生する場合は、この制限に達している可能性が考えられます。 CircleCI サポートに制限値の引き上げを依頼してください。

ビルドしようとしているプロジェクトが表示されておらず、CircleCI 上で現在ビルド中のものではない場合は、CircleCI アプリケーションの左上隅で組織を確認してください。 左上にユーザー my-user が表示されている場合、my-user に属するプロジェクトだけが Projects の下に表示されます。 your-org/project というプロジェクトをビルドする場合は、アプリケーションの組織切替メニューの組織を your-org に切り替える必要があります。

CircleCI では、現在 Docker Hub からの Docker イメージのプル (と Docker Engine のプッシュ) をサポートしています。 公式の Docker イメージの場合、単純にイメージ名やタグを指定してプルできます。

golang:1.7.1-jessie
redis:3.0.7-jessie

Docker Hub のパブリックイメージの場合は、下記のようにアカウント名やチームのユーザー名を付加してプルすることも可能です。

my-user/couchdb:1.6.1

latest タグを付けずにイメージのバージョンを指定することをお勧めします。 もしくは、特定のバージョンやタグを付けるのも良い方法です。ベースとなるイメージのディストリビューションに変更があったとき、イメージを固定し、コンテナへのアップストリームの変更を防ぐには、例えば cimg/ruby:3.0.4-browsers のように指定します。 例えば、cimg/ruby:3.0.4 のみを指定した場合、browsers から node に予期せぬ変更が加えられる場合があります。 その他の応用例は、 Docker イメージのベストプラクティスや CircleCI イメージのベストプラクティスを参照してください。

Docker イメージのタイムゾーンを設定するには、環境変数 TZ を使用します。 定義された変数 TZ を使った .circleci/config.yml の設定例は以下のようになります。

version: 2.1
jobs:
  build:
    docker:
      - image: your/primary-image:version-tag
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
      - image: mysql:5.7
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
        environment:
           TZ: "America/Los_Angeles"
    working_directory: ~/your-dir
    environment:
      TZ: "America/Los_Angeles"

この例では、プライマリイメージと mySQL イメージの両方にタイムゾーンを設定しています。

利用可能なタイムゾーンの一覧は Wikipedia で確認できます。

• Linux
• Android
• macOS
• iOS
• Windows

Docker ジョブでは amd64を、マシンジョブでは amd64 と ARM リソース をサポートしています。

IPv6 によるローカル通信のテストでは、 Machine Executor を利用できます。 残念ながら、WAN における IPv6 通信はサポートしていません。CircleCI が使用しているクラウドサービスの全てが IPv6 をサポートしているわけではないためです。

Machine Executor で実行しているホストは、eth0 や lo といったネットワークインターフェースに対して IPv6 アドレスが割り当てられます。

IPv6 環境のサービスをテストするために、コンテナに IPv6 アドレスを割り当てるよう Docker を設定することも可能です。 下記のように Docker デーモンを設定することでグローバル設定を有効にできます。

jobs:
  ipv6_tests:
    machine:
      # The image uses the current tag, which always points to the most recent
      # supported release. If stability and determinism are crucial for your CI
      # pipeline, use a release date tag with your image, e.g. ubuntu-2004:202201-02
      image: ubuntu-2004:current
    steps:
      - checkout
      - run:
          name: enable ipv6
          command: |
            cat <<'EOF' | sudo tee /etc/docker/daemon.json
            {
              "ipv6": true,
              "fixed-cidr-v6": "2001:db8:1::/64"
            }
            EOF
            sudo service docker restart

Docker に IPv6 アドレスを割り当てる手法はいくつかあります。1 つは上記のように Docker デーモンを設定する方法、2 つ目は docker network create コマンドを用いる方法、そして docker-compose を利用する方法です。

料金プランのページでプランの詳細をご確認ください。

クレジットは、マシンのタイプとサイズに基づく使用料の支払いに充てられます。 また、Docker レイヤー キャッシュなどの有料機能を使用したときにも消費されます。

たとえば、毎分 10 クレジットのレートで Docker または Linux の Medium コンピューティングオプションを利用する場合、25,000 クレジットのパッケージでは 2,500 分のビルドが可能です。 CircleCI ではパフォーマンス (開発者の生産性の向上) と価値を備えた最適なビルドを行なっていただけるよう複数のコンピューティングサイズを提供しています。

必要に応じて、並列実行を使用するとビルド時間をさらに短縮できます。並列実行により、ジョブを複数のテストに分割し、同時に実行できます。 2 倍の並列実行により、通常 2,500 分で実行されるビルドが 1,250 分で実行できるため、開発者の生産性がさらに向上します。 2つの Executor がそれぞれ 1,250 分間並行して実行している場合、合計ビルド時間は 2,500 分になります。

可能です。CircleCI アプリのサイドバーから Plan を選択し、Share & Transfer をクリックします。

Free プラン以外のプランでは、共有組織の追加オプションによりお客様が管理者としてのアクセス権を持つ Free プランの組織とプランを共有することができます。 プランを共有するすべての組織が「Share & Transfer」のページに記載され、子組織のすべてのクレジットとその他の利用料金が親組織に請求されます。

Free プラン以外のプランでは、譲渡プランオプションによりお客様が管理者としてのアクセス権を持つ他の Free プランの組織にお客様のプランを譲渡することができます。 有料プランを別の組織に譲渡した場合、お客様の組織は Free プランにダウングレードされます。

はい、その場合でも 1 分間分の料金をお支払いいただく必要があります。 1 分未満の秒単位は切り上げてクレジットを計算します。

選択したクレジットパッケージの料金が、毎月初めに請求されます。

プレミアム機能を利用するアクティブユーザーの人数分の料金、コンピューティングに対する料金のほか、Premium サポートを利用している場合はその料金も含まれます。

• マシンサイズを選べる機能などを利用するには、１アクティブ ユーザーあたり月額 25,000 クレジット (税抜) が必要です。
• コンピューティングの月額料金は、マシンのサイズと使用時間に基づいて、クレジットで支払われます。
  • 25,000 クレジットで 1 パッケージとなっており、1 パッケージは 15 ドル (税抜) です。
  • クレジットは毎月持ち越され、1 年後に失効します。
• Docker レイヤー キャッシュ (DLC) の料金は、コンピューティングと同じく、使用量に基づいてクレジットで支払われます。

CircleCI Web アプリから Plan > Plan Usage に移動してお客様のストレージとネットワークの使用状況を確認し、1ヶ月のストレージ料金とネットワーク料金を計算します。

日々の使用量から 1ヶ月のストレージ料金を計算するには、 Storage タブをクリックし、組織の月間の割り当て GB を超過していないかを確認します。 超過分（GB-Months/TB-Months）に 420 クレジットを乗じることで、1ヶ月の料金を見積もることができます。 計算例：2 GB-Months の超過 x 420 クレジット = 840 クレジット (0.5 ドル)。

ネットワークの使用に対する課金は、CircleCI からセルフホストランナーへのトラフィックに対してのみ適用されます。 詳細は こちらを参照してください。

超過分（GB/TB）に 420 クレジットを乗じることで、その月の料金を見積もることができます。 計算例：2 GB-Months の超過 x 420 クレジット = 840 クレジット (0.5 ドル)。

1ヶ月の IP アドレスの範囲機能の料金は、 CircleCI アプリで Plan > Plan Usage に移動し、IP アドレスの範囲機能の利用状況を確認して計算します。

IP アドレスの範囲機能の使用状況 のサマリーに加えて、 IP Ranges タブに移動するとお客様のデータ使用状況の詳細を確認できます。 このタブでは、IP アドレスの範囲機能の使用量の値は、 IP アドレスの範囲機能が有効なジョブの実行中の Docker コンテナ内外の未加工のバイト数を表します。

このバイト数には、ジョブの全体のネットワーク通信_および_ Docker コンテナの送受信に使われるバイトも含まれます。 IP アドレスの範囲機能が有効なジョブにおいて、ジョブの実行の開始前に Docker イメージをコンテナにプルするために使用されるデータに対しては_料金は発生しません _。

この機能は、IP アドレスの範囲機能が有効なジョブで使用されるデータ 1 GB ごとに、お客様のアカウントから 450 クレジットを消費します。 Job Details UI ページの Resources タブで各ジョブの IP アドレスの範囲機能の使用状況の詳細をご覧いただけます。 詳細は、 IP アドレスの範囲機能の料金をご覧ください。

Job Details の UI ページの Resources タブから、すべての Docker ジョブ (リモート Docker を除く) の概算ネットワーク通信量を確認できます。 GB になっていない場合は GB に変換し、450 クレジットを乗じて Docker ジョブで IP アドレスの範囲機能を有効にする場合の概算コストをお見積もりください。

クレジットは、コンピューティングの利用に対して消費されます。 CircleCI は、できるだけ使用コストを抑えながら、CI の基本的な推奨事項である「頻繁なジョブ実行」を行っていただくことを目指しています。 アクティブユーザー単位で設定しているのは、プラットフォーム機能とジョブオーケストレーションの利用に対する料金です。 たとえば、依存関係のキャッシュ、アーティファクトのキャッシュ、ワークスペースなどがあり、いずれの機能も追加のコンピューティングコストをかけずにビルド時間を短縮するのに役立ちます。

アクティブユーザーとは、非 OSS プロジェクトでコンピューティングリソースの使用をトリガーするユーザーのことです。 次のようなアクティビティが含まれます。

• ビルドをトリガーするユーザーからのコミット (PR マージ コミットを含む)
• CircleCI の Web アプリケーションでのジョブの再実行 ( SSH デバッグを含む)
• ジョブの手動承認 (承認者はすべてのダウンストリームジョブの実行者と見なされる)
• スケジュールされたワークフローの使用
• マシンユーザー

注: プロジェクトが オープンソースの場合は、アクティブユーザーとは見なされません。

アクティブユーザーの一覧は、CircleCI の Web アプリにログインし、Plan > Plan Usage > Users タブをクリックして確認できます。

Performance プランでは、0 クレジットになると、25% のクレジットサブスクリプション (最低 25,000 クレジット) が補充されます。 たとえば、毎月のパッケージ サイズが 100,000 クレジットの場合には、残りが 2,000 クレジットになると、25,000 クレジットが自動的にチャージされます (1 クレジットあたり税抜 0.0006 ドル)。

アカウントで補充が繰り返し行われている場合は、 CircleCI ウェブアプリにログインし、Plan > Plan Usage をクリックしクレジットの使用量を確認してください。 多くの場合、クレジットパッケージを増やすことにより補充の繰り返しを最小限に抑えることができます。 プランを管理するには、 Plan Overview をクリックしてください。

Free プランでは、クレジットがなくなるとジョブの実行に失敗します。

Performance プランのクレジットは、購入後 1 年で失効します。 アカウントのサブスクリプションを停止した場合も、未使用のクレジットは失効します。

毎月の料金は CircleCI アプリ内で支払えます。

Performance プランでは、請求サイクルの初日に、Premium サポートの料金と毎月のクレジットパッケージの料金が請求されます。 その月の_間_にクレジットが補充された場合 (利用可能なクレジットが 2% に達し 25% が自動補充された場合など) は、_補充時_に支払いが行われます。

いいえ。 ジョブが “queued (キューイング中)”と通知された場合、ジョブがプランや同時実行の制限により待機状態になっていることを意味しています。 ジョブが “preparing (準備中)” の場合は、CircleCI がセットアップを行っているか、ジョブの実行を 開始 しようとしているため間もなく実行される可能性があります。

CircleCI からの請求が発生する以下の日付に加え、有料プランへのアップグレードや別の有料プランへの変更をして初めてクレジットカードで決済した日付が、更新日として設定されます。

• 月間プランの場合、毎月の月額料金の請求日が更新日になります。
• 年間プランの場合、年に一度の年間料金の請求日が更新日になります。
• 年間プランを利用中でも、ユーザーの追加やクレジットの消費により未払い残高が発生した場合、その月の最終日が更新日になります。
• Performance プランでは、クレジットの残高が設定された最低残高を下回った場合、自動的にクレジット購入が実行されます。

Free プランを利用されているオープンソースの組織には、Linux オープンソースプロジェクトに使用できる 400,000 クレジットが毎月無料で付与されます。 オープンソースのクレジットの利用可能量や制限は、UI 画面上では確認できません。

CircleCI の Free プランを使用して macOS でビルドを行っている組織にも、毎月 25,000 クレジットが無料で付与され、macOS オープンソースプロジェクトのビルドに利用できます。 希望される場合は、billing@circleci.com までお問い合わせください。 macOS オープンソースのビルド用の無料クレジットは、1 組織あたり最大 2 件のジョブの同時実行に使用できます。

現在、Performance プランでオープンソースをご利用のお客様への割引は行っていません。

Docker レイヤー キャッシュ (DLC) は、変更のあった Docker レイヤーのみを再ビルドすることで、Docker イメージをビルドするパイプラインでのビルド時間を削減する機能です (DLC の詳細は こちら)。 DLC は 1 回のジョブ実行につき 200 クレジットを消費します。

お客様に DLC を安心してご利用いただくために、CircleCI ではいくつかの処理を行っています。 ソリッドステートドライブを使用し、キャッシュをゾーン間で複製し、DLC を利用可能な状態にします。 また、必要に応じてキャッシュを増やすことで、同時実行の要求に対応しながら、DLC をジョブで利用できるようにしています。 これらのさまざまな最適化によって、コンピューティングプロバイダーにより CircleCI に追加コストが発生し、そのコストはお客様が DLC を使用する際に引き継がれます。

DLC のご利用金額を見積もるには、設定ファイル内の Docker レイヤーキャッシュが有効になっているジョブと、それらのジョブでビルドしている Docker イメージの数を確認してください。 設定ファイルにジョブが 1 度だけ記述されている場合でも、たとえば並列実行を有効にした場合は、そのジョブがパイプラインで複数回実行される場合もあります。

Docker レイヤーキャッシュの効果は、Docker イメージをビルドしているパイプラインでのみはっきりと現れ、ジョブ中にビルドされるアプリケーションイメージに変更がない場合にそのレイヤーが再利用されることで、イメージのビルド時間が短縮されます。 パイプラインに Docker イメージがビルドされたジョブが含まれていない場合、Docker レイヤーキャッシュのメリットは得られません。

コンテナベースプランの提供は終了しました。 コンテナベースプランを利用されていて、従量課金制プランに移行する手順については、 Discuss の投稿 をご覧ください。