Search Results for ""

よくあるご質問

一般

CircleCI の従業員にプログラムコードを見られる恐れはありませんか?

CircleCI の従業員がユーザーの許諾を得ずにコードを見ることはありません。 サポートをご希望の際、 サポートエンジニアが問題解決を図るために許可を得たうえで コードを確認させていただく 場合があります。

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

開発環境の移行

CircleCI 1.0 から 2.0 へ移行するメリットは?

  • CircleCI 2.0 ではコンテナの使い方に関する大幅な仕様変更があり、多数のジョブの高速化と、使用可能なコンテナのアイドル化状態の防止を図っています。
  • CircleCI 2.0 では 1 つのジョブはステップ内に記述されます。ジョブ内のそれぞれのステップは自由に編集でき、ビルドの方法を好きなように、柔軟にカスタマイズすることが可能になりました。
  • CircleCI 2.0 のジョブでは、公開されているあらゆる Docker イメージはもちろん、独自に依存関係を設定しているカスタムイメージも利用できます。

Jenkins から CircleCI 2.0 へ移行するには?

Hello World を例を挙げると、下記のように Jenkins の steps に記述している内容をそのまま steps: にコピー&ペーストすることになります。

    steps:
      - run: echo "bash コマンドをここに記述します"
      - run:
          command: |
            echo "2 行以上の bash コマンドはこのようにします"
            echo "たいていは Jenkins の Execute Shell の内容をコピー&ペーストするだけです"

Jenkins と CircleCI の仕組みの違いについては「Jenkins からの移行」をご覧ください。

CircleCI 2.0 では 1.0 にあった inference コマンドを実行してくれますか?

CircleCI 2.0 はプロジェクトの内容から推測して変換するようなことはしません。あらかじめ用意された定型の config.yml ファイルから選択できるスマートデフォルト型のインターフェースを利用する方向で進めています。

CircleCI 2.0 は元となる OS イメージを新たに作成しなくても使えますか?

もちろん使えます。CircleCI が提供している OS イメージをご利用ください。ただし、将来的にそれらの OS イメージが使えなくなる可能性がある点についてはご了承ください。

例えば circleci/build-image:ubuntu-14.04-XL-922-9410082 というイメージは、Trusty 版の Ubuntu 14.04 と同等の内容になっています。 容量はかなり大きく(非圧縮時 17.5GB 程度)、ローカル環境でテストするのにはあまり向いていないかもしれません。

このイメージではデフォルトで ubuntu ユーザーとして実行され、Docker Compose によって提供されるネットワークサービスを稼働させる用途に適しています。

詳しくは、イメージに含まれている言語やツールの一覧をご覧ください。

ホスティング

CircleCI 2.0 はオンプレミスでの利用も可能ですか?

可能です。CircleCI 2.0 はオンプレミス環境を必要とされるエンタープライズにもご利用いただけます。詳しいインストール手順については「管理者向け概要」をご覧ください。

CircleCI のホスティングの種類は?

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

  • オンプレミス型 : AWS などと同じようにユーザーが CircleCI のインストールと管理を行います。ファイアウォール環境におけるサーバーの初期設定とメンテナンスも、ユーザー自身がデータセンターのポリシーにしたがって実施します。自在なカスタマイズや新バーションへのアップグレードの制御など、あらゆる管理権限があります。

どうして CircleCI Enterprise という名称をやめたのですか?

Enterprise はファイアウォールのあるオンプレミス環境で利用可能なオプションを指すものでした。ただ、ユーザーの皆様や CircleCI のスタッフにとってまぎらわしい用語でもありました。

そのため、クラウドサービス経由で使えるもの、ファイアウォール環境に導入するもの、あるいはそのハイブリッドで活用するもの、というように、ニーズに応じて利用可能な CircleCI という 1 つの製品としました。

トラブルシューティング

コミットをプッシュしてもジョブが実行されない理由は?

CircleCI の Workflows タブで エラーメッセージを 確認してみてください。 たいていの場合 は config.yml ファイル内での文法エラーが原因です。 詳しくは「YAML の書き方」をご確認ください。

config.yml の文法エラーをチェックして、 それでもなお解決しないときは「ナレッジベース」で検索してみてください。

「usage キュー」と「run キュー」の違いはなんですか?

usage キュー は、1 つの組織において ビルドを実行するためのコンテナが不足しているときに 使われるものです。 使用可能なコンテナの数は、 CircleCI でプロジェクトを設定したときに 選んだプランによって決まります。 ビルドがキューに入りがちな場合は、 プランを変更して使用可能なコンテナ数を 増やすことをおすすめします。

run キュー は CircleCI 自体が高負荷な状況に 陥っているときに発生します。 この場合、ユーザーのビルドはいったん run キューに置かれ、 マシンが利用できる状態になったら処理されます。

つまり、usage キュー が発生するときは コンテナの数を増やすことで 処理時間を短縮できますが、 run キュー による待ち時間は 避けようがないということになります(もちろん CircleCI では可能な限りそうならないよう務めます)。

「Add Project」ページにプロジェクトが見つからないのはなぜですか?

ビルドしようとしているプロジェクトが見当たらず、目的のビルドでないものが表示されている場合は、画面左上にある Org を確認してください。もし左上に見えるのがあなたのユーザー名 my-user だったとすると、my-user に属する GitHub プロジェクトだけが Add Projects の下に表示されることになります。GitHub のプロジェクト名 your-org/project をビルドしたいということであれば、画面左上のエリアをクリックすると表示される [Switch Organization] メニューから目的の Org である your-org に切り替えます。

「build didn’t run because it needs more containers than your plan allows」というエラーが表示されます。しかし、現在のプランはその条件を満たしています。なぜエラーになるのでしょうか?

CircleCI では、基本的には 1 プロジェクトあたりの並列処理数が 16 までに制限されています。この数を超えてリクエストした場合、ビルドは失敗してしまいます。上限を大きくしたいときは CircleCI Japanese Support Center よりお問い合わせください。

Docker イメージの名前の付け方は? 見つけ方を教えてほしい。

CircleCI 2.0 では現在のところ Docker Hub 上の Docker イメージのプル(と Docker Engine のプッシュ)にのみ対応しています。これら公式の Docker イメージに対してできるのは、単純に下記のような名前やタグを指定してプルすることです。

golang:1.7.1-jessie
redis:3.0.7-jessie

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

my-user/couchdb:1.6.1

Docker イメージのバージョンを指定するときのベストな方法は?

Docker イメージを指定する際に、latest タグを付け ない のが正しい方法です。もしくは、特定のバージョンやタグを付けるのも良い方法です。ベースとなるイメージのディストリビューションに変更があったとき、イメージが変更されないようにしてアップストリームにコンテナへの影響を防ぐには、例えば circleci/ruby:2.4-jessie-node のように指定します。circleci/ruby:2.4 とだけ指定した場合は、jessie から stretch への予期しない変更による影響を受ける可能性があります。他の応用例を知りたいときは、「Executor タイプの選び方」のDocker イメージ活用のヒントや、「CircleCI のビルド済み Docker イメージ」のビルド済みイメージの活用方法を参照してください。

Docker イメージでタイムゾーンを設定する方法は?

環境変数 TZ を用いて Docker イメージのタイムゾーンを設定できます。下記のように .circleci/config.yml を編集してみてください。

環境変数 TZ を定義する .circleci/config.yml の設定例

version: 2
jobs:
  build:
    docker:
      - image: your/primary-image:version-tag
      - image: mysql:5.7
        environment:
           TZ: "America/Los_Angeles"
    working_directory: ~/your-dir
    environment:
      TZ: "America/Los_Angeles"

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

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

Workflows

Workflows のなかで API は使えますか?

使えます。利用方法や API エンドポイントの URL については「ビルド処理の有効化」をご覧ください。

Workflows でビルドの「自動キャンセル」はできますか?

可能です。「ビルドのスキップ・キャンセル」で設定手順をご確認ください。

テスト結果を保存する store_test_results を Workflows 内で使えますか?

テスト結果のデータを [Test Summary] というセクションに記録するのに、store_test_results が使えます。また、データを時系列順に分割する際にも使えます。時系列のテストデータは CircleCI 2.0 の Workflows より利用できるようになったもので、同一名称のジョブで使っているデータは 50 ビルド分さかのぼることができます。

CircleCI 1.0 で Workflows を使うことはできますか?

Workflows は CircleCI 2.0 固有の機能です。Workflows を利用するには CircleCI 2.0 でビルドを実行する必要があります。

オンプレミス環境にインストールした CircleCI でも Workflows は使えますか?

もちろん使えます。Workflows は CircleCI 2.0 の 1 機能としてエンタープライズ向けのオンプレミス環境でもご利用いただけます。CircleCI のインストール手順などについては「管理者向け概要」を参照してください。

同時に実行できるジョブの数はいくつですか?

契約しているプランにおける利用可能なコンテナ数が、同時に実行可能なジョブの数を決めることになります。仮に 10 個の Workflows ジョブが実行されようとしていて、プラン上は 5 つのコンテナしか使えない場合は、実行されるのは一度に 5 つのジョブまでです。 Workflow の設定を行うことで、複数のジョブを同時もしくは連続的に実行できます。ファンアウト(複数のジョブを同時実行する)、あるいはファンイン(その前の独立したジョブが完了するまで以降の全ジョブを待機させる)が可能です。

同一の Workflow 内で Linux 環境と Mac 環境両方のジョブを実行できるようにする機能が追加される予定はありますか?

すでにサポートしています。「config.yml の設定例」内の複数の実行環境 (macOS + Docker) を利用する設定例を参照してください。

config.yml ファイルの内容を複数ファイルに分割することはできますか?

config.yml の内容を複数のファイルに分割する機能は今のところ提供していません。

変更のあった単一のジョブのみをビルドできますか?

できません。

Workflows でフォークするプルリクエストをビルドすることは可能ですか?

可能です!

Workflows を指定した日時にスケジュール実行することは可能ですか?

CircleCI がホスティングしているクラウド環境なら可能です。例えば、午後 4 時に Workflow を実行するなら、cron: キーの値として "0 16 * * *" を指定します。時刻は UTC 協定世界時のタイムゾーンとなります。今後はオンプレミス環境の CircleCI でも Workflows のスケジュール実行が可能になるよう計画しています。

スケジュール実行の際に使われるタイムゾーンは?

スケジュール実行におけるタイムゾーンは UTC 協定世界時に合わせられます。

ビルドのスケジュール実行が失敗する理由は?

スケジュール実行する Workflow のブランチを正確に指定したうえで、ビルドしたいブランチに対して config.yml ファイルをプッシュしてください。master ブランチにおけるプッシュは、master ブランチに対する Workflow しかスケジュールされません。

複数の Workflows をスケジュール実行できますか?

可能です。trigger: キーのなかで schedule が設定された Workflow は、どれも指定されたスケジュールで実行されます。

スケジュールされた Workflows は、指定された時間通り正確に実行されますか?

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

料金・支払

コンテナ課金プラン

ビルドがキューに入らないようコンテナ数を増やしたい。現在の契約プランからアップグレードするには?

  • Linux プランの変更:CircleCI で [Settings] → [Plan Overview] 画面を表示し、[Add Containers] ボタンをクリックします。表示される入力欄に増やしたい数をタイプしたら、[Pay Now] ボタンをクリックして支払方法の設定画面へと進みます。

  • macOS プランの変更:CircleCI で [Settings] → [Plan Overview] 画面を表示し、[Change Plan] ボタンをクリックします。[Startup] もしくは [Growth] を選び、[Pay Now] ボタンをクリックして支払い方法の設定画面へと進みます。

異なる Org 間で契約プランを共有できますか? その場合、請求を 1 箇所にまとめることは?

可能です。CircleCI で [Settings] → [Share & Transfer] → [Share Plan] ページと進み、プランを共有したい Org を選択してください。

個人アカウントではなく Org 宛に請求されるよう設定できますか?

可能です。請求は Org にひもづけられます。Org の設定ページにて、ユーザー自身がその Org として支払うことができます。ただし、そのユーザーが全てのプロジェクトから外れる場合、それらを引き継ぐ別の GitHub Org 管理者をたてる必要があります。将来のアップデートではよりわかりやすい解決策を提供できる予定です。

課金におけるコンテナの定義は?

料金を支払って利用できるコンテナ 1 個は、2 つの CPU と 4GB のメモリを搭載するマシンです。コンテナはタスクの同時実行(5 つの異なるジョブを実行するなど)や並列実行(1 つのジョブを 5 つの異なるタスクに分解してそれぞれを一斉に実行するなど)を行うのに使われます。この場合はどちらの例でも 5 つのコンテナが必要になります。


従量課金制(クレジット)プラン

新しい料金プランが導入されることで何か変化はありますか?

ご利用中のプランは引き続きお使いいただけます。現在のご利用状況に合わせこの新しいプランもご検討ください。

クレジットとは何ですか?

クレジットは料金の支払いに利用される単位です。利用したマシンのタイプやサイズによって消費されるクレジット数は異なります。 またクレジットは、Docker レイヤーキャッシュなどを使用する際にも消費されます。

例えば、毎分 10 クレジットのデフォルトレートで 1 台のマシンを使用する場合、25,000 クレジットのパッケージでは 2,500 分のビルドが可能です。 同じパッケージで 2 倍の並列処理を使用する場合は 1,250 分、また 10 倍の並列処理を使用する場合は 250 分のビルドが可能です。

コンテナの使用時間が 1 分未満の場合でも 1 分間の料金を支払う必要がありますか?

はい、1 分間の料金をお支払いいただきます。1 分未満の秒単位は切り上げでクレジットを計算します。

クレジットの購入方法は? 必要な時に必要な分だけ購入できますか?

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

支払う料金の内訳は?

プレミアム機能を利用するアクティブユーザー数分の料金、コンピューティングに対する料金、またオプションで利用できるプレミアムサポート料金になります。

  • マシンサイズを選べる機能などを利用するには、1 アクティブユーザーあたり $15/月が必要です。
  • コンピューティングに対する毎月の料金は従量課金制(クレジット)になります。クレジットの月間消費量はマシンのサイズと使用した時間で決まります。
  • Docker レイヤーキャッシュ(DLC)に対する料金は、コンピューティングに対する料金同様、 使用回数による従量課金制(クレジット)になります。

クレジットを使い切るとどうなりますか?

Performance プランでは、クレジットの残高が 5% になると、10% のクレジットがチャージされます。 例えば、毎月のパッケージサイズが 25,000 クレジットの場合、クレジットの残高が 1,250 になると、2,500 クレジットが自動的にチャージされます。

クレジットに有効期限はありますか?

Performance プラン : クレジットの有効期限は購入から 1 年になります。ただし、プランを解約すると、未使用のクレジットは無効となり、利用できなくなります。

支払い方法は?

毎月の料金は CircleCI の設定画面からお支払いいただけます。

支払いのスケジュールは?

従量課金制(クレジット)プランでは、請求サイクルの初日に、利用するユーザー数分の料金、プレミアムサポート料金、選択したクレジットパッケージ料金が請求されます。請求サイクルの 月途中 で発生したチャージ分(クレジットの残高が 5% になった際に実行されるオートチャージ分など)は、チャージ実行時 に請求されます。

有料プランの更新日は?

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

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

稼働環境

テスト時に IPv6 は利用できますか?

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

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

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

   ipv6_tests:
     machine: true
     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 を利用する方法です。

CircleCI 2.0 がサポートしている OS は?

  • Linux : CircleCI はほとんどの Linux アプリケーションのビルドが可能な高い柔軟性をもっています。Web アプリケーションはもちろん、それ以外のビルドにも利用できます。

  • Android : 詳細は「言語別ガイド : Android」をご覧ください。

  • iOS :iOS プロジェクト チュートリアル」でビルド方法を確認できます。

  • Windows : Windows アプリケーションのビルドとテストは現在サポートしていません。

CircleCI がサポートしている CPU アーキテクチャは?

サポートしている CPU アーキテクチャは amd64 のみとなります。