トラブルシューティング

未承認 Orb の使用を有効にするには、お客様の組織の設定ページから Security タブをクリックします。 その後、yes をクリックして未承認 Orb を許可するを有効にします。

コマンド:

エラー：

このエラーを解決するには、設定で circleci config process を実行し、その設定をディスクに保存します。 次に、処理された設定に対して circleci local execute を実行します。

お客様は組織オーナーまたは管理者でない可能性があります。

組織が要求できる名前空間は 1 つだけです。 組織の名前空間を要求するには、認証を行うユーザーがその組織内でオーナーまたは管理者の権限を持っている必要があります。

必要な権限レベルがない場合、下記のようなエラーが表示されることがあります。

詳細については、 Orb CLI の権限リストを参照してください。

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

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 イメージの場合、単純にイメージ名やタグを指定してプルできます。

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

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

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

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

設定できるタイムゾーンの一覧は、 Wikipedia でご確認ください。

ディスク容量の不足により Pod へのボリュームマウントが失敗する旨の警告が表示され、タスクは Preparing Environment ステップで停滞します。

十分なディスク容量があることを確認してください。

Pod がホストされているノードのメモリが不足すると、タスクが失敗し、 Runner Instance Failure という名前の失敗ステップと以下のメッセージが表示されます。

kubectl を使って Kubernetes で表示すると、Pod のステータスは OOMKilled になります。 タスク Pod の設定を使って、ジョブ自体のメモリーの割り当てを管理できます。

ノードがいっぱいになると、 node.kuberenetes.io/disk-pressure という Taint が表示され、新しいタスク Pod をスケジュールできなくなります。 この Pod のすべての有効なノードに同じ Taint またはスケジュールを妨げるその他の条件があると、そのタスク Pod は Taint されていない有効なノードが使用できるようになるまで保留状態になります。 これにより、このジョブが UI の Preparing Environment ステップで停滞しているように見えます。

この状態にならないよう、クラスタをより効果的にスケーリングるする必要があります。

コンテナランナーが別の Node でホストされている場合、タイムアウトになるまでタスクは CircleCI UI で実行されているように見えます。 kubectl も、クラスタの liveness Probe のタイムアウトになるまで、Pod を実行中として表示します。 Podは terminating 状態になり、そのまま停滞します。 この時点で、Pod を強制的に削除する必要があります。 強制的に削除しないと、kubectl がハングする場合があります。

イメージに指定されたエントリポイントが無効な場合、タスクが失敗し、エラーになります。

コンテナランナーとクラウド版 CircleCI では、 プライマリコンテナ のエントリポイントの設定方法が異なります。 クラウドの場合、プライマリコンテナのエントリポイントは com.circleci.preserve-entrypoint=true LABEL 指示を使用して保持されていない限り無視されます ( エントリポイントの追加 を参照)。 一方コンテナランナーの場合、常にシェル (/bin/sh) がデフォルト設定されるか、ジョブ設定でエントリポイントが指定されている場合はそれが設定されます。

注: エントリポイントは、失敗せずに最後まで実行される必要があります。 失敗した場合、またはビルドの途中で停止した場合は、ビルドも停止します。 ログまたはビルドステータスにアクセスする必要がある場合は、エントリポイントの代わりにバックグラウンドステップを使用します。

このエラーを減らすには、 エントリポイントの追加 に関するドキュメントに沿ってエントリポイントを指定します。 カスタムビルドされた Docker イメージの使用 に記載されているようにエントリポイントを明示的に設定します。

ジョブのイメージがデプロイされているノードと異なるアーキテクチャを使用している場合、コンテナランナーはエラーになります。

タスク Pod にはエラーステータスも表示されます。 CircleCI UI で失敗したジョブとしてエラーとともにに表示されます。

ジョブを使ってノードに使用されている基盤アーキテクチャをジョブで使用されているイメージのアーキテクチャに合わせて修正する必要があります。

リソースクラスのタスク Pod の設定が誤っている場合、タスクは要求されると失敗します。 UI では、このエラーは Runner Instance Failure ステップに入り、以下のようなメッセージが表示されます。

Kuberenetes クラスタで Pod が一つも作成されていない タスク Pod の設定を、 コンテナランナー に記載されているように修正する必要があります。

コンテナランナーで実行されるジョブで使用するカスタムイメージには Bash が必要です。

もし、「Oops, there was an issue with your infrastructure」というメッセージが表示された場合。 セルフホストランナーのインフラストラクチャが動作していることを確認し、ジョブを再実行してみてください。 それでも問題が解決しない場合は、ジョブのページにある「トラブルシューティングガイド」を参照するか、タスクのライフサイクルステップにコンテンツがない場合（図のような場合）、以下に説明する潜在的な原因を検討する必要があります：

kubectl exec --stdin --tty -n circleci < full pod name > — /bin/sh コマンドを使って Pod に接続し、ping テストを長時間実行することを推奨します。 また、 CircleCI のセルフホストランナーに必要な接続 についてのセクションが含まれる「よく寄せられるご質問」のリンクへの接続を確認することを推奨します。

リソースの使用量を監視できる外部ツールもあります。 Kubernetes のドキュメント をご覧ください。

場合によっては、root で実行できるように、ローンチエージェントの実行権限を更新する必要があります。 以下の 2 つのコマンドを実行してください。

ジョブをキャンセルし、再実行します。 それでもジョブが実行されない場合は、 サポートチケット を送信してください。

CircleCI マシンランナーでは、デバッグのために SSH 接続でジョブを再実行することが可能です。 この機能の使用に関する詳細は、 SSH を使用したデバッグをご覧ください。