IBM Cloud Docs
GitHub、GitLab、および Git Repos and Issue Tracking に関するトラブルシューティング

GitHub、GitLab、および Git Repos and Issue Tracking に関するトラブルシューティング

GitHub、GitLab、および Git Repos and Issue Tracking を使用中に生じる可能性がある一般的な問題として、GitHub の認証、ツール統合の構成に関する問題などが挙げられます。 多くの場合、いくつかの簡単なステップを実行することで、これらの問題から復旧することが可能です。

GitHub ツール統合をツールチェーンに追加しようとしたのですが、ツール統合が追加されませんでした。

GitHub アカウントへのアクセスが IBM Cloud に許可されるように、GitHub で許可を付与する必要があります。

GitHub ツール統合がツールチェーンに追加されませんでした。 Terraform または API を使用して GitHub ツール統合を作成する場合、試行は失敗し、 User is not authorized with https://api.github.com エラー・メッセージが表示されます。

IBM Cloud に GitHub アカウントへのアクセスを許可していない場合、ツール統合はツールチェーンに追加されません。

ツールチェインの作成中にコンソールを使用してGitHubツール統合を設定する場合は、以下の手順に従ってGitHub:との認証を行います：

  1. 「構成可能な統合 (Configurable Integrations)」セクションで**「GitHub」**をクリックします。

  2. If you are creating the toolchain on IBM Cloud Public and IBM Cloud is not authorized to access GitHub, select the method of authentication that will be used to access Github.

    • OAuth を選択した場合は、 「Authorize」 をクリックして GitHub Web サイトにアクセスします。 アクティブな GitHub セッションがない場合は、ログインするよう求められます。 AuthorizeIBM to allowIBM Cloudto access yourGitHubaccount.
    • Personal Access Token を選択した場合は、 GitHubの有効な個人アクセス・トークンを指定します。

コンソールを使用していて、既にツールチェーンがある場合は、 GitHub ツール統合の構成を更新します。

  1. IBM Cloudコンソールから、メニューアイコンの ハンバーガーアイコン>Platform Automation>Toolchains をクリックします。 「ツールチェーン」ページで、ツールチェーンをクリックしてその「概要」ページを開きます。 または、アプリの「概要」ページの「継続的デリバリー」カードで、「ツールチェーンを表示」＞「概要」をクリックする。

  2. ツールチェーンの「概要」ページの**「リポジトリー」**カードで、GitHub ツール統合を見つけます。

  3. メニューをクリックして構成オプションにアクセスし、IBM Cloud が GitHub にアクセスすることを許可するように構成設定を更新します。

    • OAuth を選択した場合は、 「Authorize」 をクリックして GitHub Web サイトにアクセスします。 アクティブな GitHub セッションがない場合は、ログインするよう求められます。 AuthorizeIBM to allowIBM Cloudto access yourGitHubaccount.
    • Personal Access Token を選択した場合は、 GitHubの有効な個人アクセス・トークンを指定します。

  4. 設定の更新が完了したら、**「統合の保存」**をクリックします。

OAuth 認証方式で Terraform または API を使用している場合は、個人アクセス・トークン (PAT) の使用に切り替えて、特定のユーザーまたはリポジトリーに細分化されたアクセス権限を付与します。 Terraform または API を使用する場合は、PAT を使用して許可することをお勧めします。 それ以外の場合は、コンソールを使用して、 IBM Cloud が GitHub アカウントにアクセスすることを許可できます。

  1. IBM Cloudコンソールから、メニューアイコンの ハンバーガーアイコン>Platform Automation>Toolchains をクリックします。 Toolchainsページで、GitHubツール統合を追加したいツールチェーンを探します。 ツールチェーンをクリックすると、その概要ページが開きます。
  2. ToolchainのOverviewページで、Add をクリックする。
  3. 「ツール統合の追加」 ページで、 GitHub ツール・カードをクリックします。
  4. 「 GitHub ページで、 「許可 (Authorize)」 をクリックして、 GitHub Web サイトに移動します。 アクティブな GitHub セッションがない場合は、ログインするよう求められます。 AuthorizeIBM to allowIBM Cloudto access yourGitHubaccount. GitHubの設定ページにリダイレクトされます。
  5. コンソールでこれ以上アクションを実行せずにページを閉じてから、Terraform または API との GitHub ツール統合の作成を再試行してください。

あるリージョンのツールチェーンに含まれる Git Repos and Issue Tracking ツール統合を、別のリージョン内のツールチェーンで使用できないのはなぜですか?

Git Repos and Issue Tracking のインスタンスは、複数のリージョンをまたいで使用することはできません。

Git Repos and Issue Tracking ツール統合をツールチェーンに追加しようとすると、次のエラー・メッセージを受け取ります。

Repository URL is not valid. The repository must be on {local GitLab URL}.

ここで、{local GitLab URL} は、ツールチェーンが置かれているリージョンにおける、Git Repos and Issue Tracking ツール統合の URL です。

Git Repos and Issue Tracking と Continuous Delivery サービスは、共に稼働しているリージョン内で緊密に統合されているため、複数のリージョンをまたいで Git Repos and Issue Tracking のインスタンスを使用することはできません。

Git Repos and Issue Tracking ツール統合を作成する代わりに、汎用 GitLab 統合を作成し、この統合を使用して別のリージョンにある Git Repos and Issue Tracking リポジトリーを参照するようにしてください。

  1. IBM Cloudコンソールから、メニューアイコンの ハンバーガーアイコン>Platform Automation>Toolchains をクリックします。 「ツールチェーン」ページで、その統合を追加するツールチェーンをクリックします。 あるいは、アプリの「概要」ページの「継続的デリバリー」カードで、**「ツールチェーンの表示」をクリックし、「概要」**をクリックします。

  2. **「ツールの追加」**をクリックします。

  3. 「ツール統合」セクションで**「GitLab」**をクリックします。

  4. 使用する GitLab サーバーをクリックします。 アクセスしようとしているリポジトリーがある GitLab サーバーが、このリストに表示されていない場合は、カスタム・サーバーを追加します。

    a. カスタムサーバーをクリックします。

    b. サーバーの名前を入力します。 このサーバー名は、使用可能な GitLab サーバーのリストに表示されます。

    c. カスタム GitLab サーバーのルート URL を入力します。

    d. カスタム GitLab サーバーの個人用アクセス・トークンを入力します。 個人用アクセス・トークンがない場合は、それを作成します。

  5. 既存の GitLab リポジトリーを使用する場合は、リポジトリーのタイプとして**「既存」**をクリックし、URL を入力します。

  6. 新しい GitLab リポジトリーを使用する場合は、そのリポジトリーに付ける名前を入力し、複製またはフォークするリポジトリーの URL を入力し、リポジトリー・タイプを次のように選択します。

    a. 空のリポジトリーを作成する場合は、**「新規」**をクリックします。

    b. GitLab リポジトリーのコピーを作成する場合は、**「クローンを作成する (Clone)」**をクリックします。

    c. GitLab リポジトリーをフォークし、マージ・リクエストで変更内容を提供できるようにする場合は、**「フォーク (Fork)」**をクリックします。

  7. サーバー上にパブリック・リポジトリーを作成する場合は、**「このリポジトリーをプライベートにする (Make this repository private)」**チェック・ボックスをクリアします。

  8. 問題のトラッキングに GitLab Issues を使用する場合は、**「GitLab Issues を使用可能にする (Enable GitLab Issues)」**チェック・ボックスにチェック・マークを付けます。

  9. コミットに対するタグおよびコメントと、コミットで参照される問題に対するラベルおよびコメントを作成することによって、コード変更のデプロイメントをトラッキングしたい場合は、**「コード変更のデプロイメントを追跡する (Track deployment of code changes)」**チェック・ボックスにチェック・マークを付けます。 詳しくは、ツールチェーンでコードがどこにデプロイされたかを追跡するを参照のこと。

  10. 「統合の作成」 をクリックします。

GitLab ツール統合の構成について詳しくは、GitLab の構成を参照してください。

https を使用して Git Repos and Issue Tracking リポジトリーを複製することができないのはなぜですか?

Git 操作を実行するときには個人用アクセス・トークンまたは SSH 鍵を使用する必要があります。

コマンド・ラインから https を使用してリポジトリーをプッシュまたは複製しようとしましたが、正しいパスワードを入力したのに認証できません。

Git Repos and Issue Tracking が使用するシングル・サインオン・メカニズムは、コマンド・ラインでユーザー名とパスワードを使用する Git 認証をサポートしていません。

複製またはプッシュなどの Git 操作を実行するには、個人用アクセス・トークンまたは SSH 鍵を使用する必要があります。 個人用アクセス・トークンまたは SSH 鍵の作成について詳しくは、入門チュートリアルを参照してください。

SSH を使用して Git Repos and Issue Tracking リポジトリーを複製しようとすると認証を求めるプロンプトが出されるのはなぜですか?

SSH 秘密鍵の場所または許可に問題がある可能性があります。あるいは、Git コマンド・ラインで、Git Repos and Issue Tracking での認証のために SSH 秘密鍵を使用していない可能性があります。

Git Repos and Issue Tracking ユーザー・インターフェースを使用して、SSH 公開鍵を追加しました。 SSH を使用してリポジトリーを複製しようとすると、パスワードまたはセキュリティー・コードの入力を求めるプロンプトが出されるか、あるいは認証の失敗を示すエラー・メッセージが表示されます。

SSH に関して以下のいずれかの問題があると、認証を求めるプロンプトが出されるか、エラー・メッセージが表示される可能性があります。

  • Git コマンド・ラインで、Git Repos and Issue Tracking での認証のために SSH 秘密鍵を使用していない可能性がある。

  • SSH 秘密鍵がデフォルトの場所 ~/.ssh/id_rsa に存在しない可能性がある。

  • SSH 秘密鍵に正しい許可 (600) が付与されていない可能性がある。

この問題を解決するには、以下のいずれかの方法を使用します。

  • SSH 秘密鍵のデフォルトの場所を使用する場合は、~/.ssh/ フォルダーと ~/.ssh/id_rsa 秘密鍵ファイルに対する許可を確認します。 許可の範囲が広すぎる場合、デフォルトでは、SSH で秘密鍵が使用されません。 ~/.ssh/ フォルダーの許可が 700 に設定されていて、~/.ssh/id_rsa フォルダーの許可が 600 に設定されていることを確認してください。

  • 秘密鍵がデフォルトの場所にない場合は、次のコマンドを使用して環境変数で指定してください。

  GIT_SSH_COMMAND='ssh -i/path/to/private_key_file' git clone git@host:owner/repo.git
  • 接続情報を使用してこの問題をデバッグするには、-v フラグまたは -vvv フラグを GIT_SSH_COMMAND 環境変数に追加します。
  GIT_SSH_COMMAND='ssh -vvv git clone git@host:owner/repo.git

  GIT_SSH_COMMAND='ssh -vvv -i/path/to/private_key_file' git clone git@host:owner/repo.git

Git Repos and Issue Tracking リポジトリーから変更内容をフェッチしようとすると、504 Gateway Time-out エラーが発生するのはなぜですか?

お客様のリポジトリーの大きさが 1 GB を超えています。 Git ソース制御管理システムは、大容量のバイナリー・ファイルを格納するようには設計されていません。

Git Repos and Issue Tracking リポジトリーでの操作 (フェッチやクローンなど) を実行しようとすると、次のエラー・メッセージを受け取ります。

git fetch error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out fatal: The remote end hung up unexpectedly

1 GB より大きい大容量のリポジトリーがあります。 さらにそのリポジトリーには、圧縮フォーマットで格納されるテキスト・ファイルより多くのスペースを必要とするバイナリー・ファイルが含まれている可能性もあります。

この問題を解決するには、以下のいずれかの方法を使用することができます。

  • Git Repos and Issue Tracking リポジトリーのサイズを小さくする。 リポジトリのサイズを小さくする方法については、Gitてリポジトリのサイズを小さくするをご覧ください。

  • SSH を使用して、デフォルトの 180 秒のクローン・タイムアウトを迂回する。

  • リポジトリーのクローンを試行する場合は、コミット履歴を切り捨てることによって転送対象データ量を削減するシャロー・クローン (git clone --depth) を実行する。 浅いクローンの完成についての詳細は、Gitリファレンスのドキュメントを参照してください。

E メールを使用してユーザーを GitLab プロジェクトに追加しようとしましたが、そのユーザーは招待を受信しませんでした。 ユーザーをプロジェクトに追加するにはどうすればよいですか?

ユーザーの E メールで招待がブロックされている可能性があります。

Git Repos and Issue Tracking にリストされている E メール・アドレスを使用してユーザーを GitLab プロジェクトに招待しましたが、そのユーザーは E メールを受信しませんでした。

メールが、スパム・フィルターによってユーザーの受信ボックスからブロックされている可能性があります。

この問題を解決するには、以下のいずれかの方法を使用することができます。

  • E メール・スパム・フォルダーを調べて、招待 E メールがスパムとしてマーク付けされていないか確認します。 E メールは noreply@ アドレスから送信されます。 このアドレスからの E メールを許可するように、スパム・フィルターを更新してください。

  • ユーザーが制御できない企業のスパム・フィルターによって、E メールがブロックされていないかどうか調べます。 ユーザーに、Git Repos and Issue Tracking ユーザー・インターフェースにログインしてユーザー ID を送信するよう依頼してください。 そのユーザー ID を使用して、GitLab プロジェクトにユーザーを追加できます。

Terraform を使用して既存の Git ツール統合の構成を更新するときに、構成が失敗するのはなぜですか?

Git ツール統合リソースは、 clone、 fork、または new の type を指定し、既存のターゲット・リポジトリーを指定します。

Terraform を使用して Git ツール統合を更新すると、構成が失敗し、 The nonempty repository _REPO-URL_ already exists. Either delete the repository or change the Repository Type to 'Existing' というエラー・メッセージが表示されます。ここで、 REPO-URL はターゲット・リポジトリーの URL です。

このエラーは、多くの場合、以下のアクションによって発生します。

  • Git ツール統合 Terraform リソースは、 clone、 fork、または new の type を指定します。 リソースの initialization ブロック内の repo_url が、存在するリポジトリーの URL に変更されました。
  • Git ツール統合 Terraform リソースは、 clone、 fork、または new の type を指定します。 repo_url を変更しませんでしたが、リソースの initialization ブロック内の 1 つ以上の他の引数を変更しました。 この場合、リポジトリーは、 Git ツール統合リソースが以前に Terraform によって適用されたときに作成されたために存在します。

clone、 fork、および new の各タイプは、このリポジトリーが存在しないことを前提としてターゲット・リポジトリー (repo_url) を作成するように Git ツール統合に指示します。 ツール統合がターゲット・リポジトリーを検出すると、意図的に失敗します。

type を clone、 fork、または new から clone_if_not_exists、 fork_if_not_exists、または new_if_not_exists に変更します。 これらのタイプは、 Git ツール統合に対して、ターゲット・リポジトリーが存在しない場合はそれを作成し、存在する場合はそのままターゲット・リポジトリーを使用するように指示します。

このエラーを解決するために他の方法を使用することもできますが、情報が失われる可能性があるため、これらの方法は推奨されません。 これらの方法では、優れたプラクティスではない変更が Terraform に必要になる場合もあります。

  • repo_url を、Terraform を再度適用したときに作成されたリポジトリーに変更します。 最初の作成後に Terraform リソースを変更して、後続の更新中のエラーを回避することは、アンチ・パターンです。 また、この方法では、以前に作成したリポジトリーはそのまま残りますが、ツールチェーンにはバインドされなくなります。
  • type を existing に変更してから、Terraform を再度適用します。 最初の作成後に Terraform リソースを変更して、後続の更新中のエラーを回避することは、アンチ・パターンです。
  • ターゲット・リポジトリーを手動で削除してから、Terraform を再度適用してください。 自動化されていない Terraform 操作間の手動変更は推奨されません。 リポジトリーを削除すると、削除を元に戻すことはできず、永続的なデータ損失が発生する可能性があります。