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. 在“可配置的集成”部分中，单击 GitHub。

  2. 如果您在IBM Cloud上创建工具链Public 上创建工具链，且IBM Cloud无权访问GitHub,选择用于访问 Github 的身份验证方法。

    • 如果选择 OAuth，请单击 授权 以转至 GitHub Web 站点。 如果您没有活动的 GitHub 会话，那么系统会提示您登录。 单击授权IBM，允许IBM Cloud访问您的GitHub账户。
    • 如果选择 Personal Access Token，请为 GitHub指定有效的个人访问令牌。

如果您正在使用控制台并且已有工具链，请更新 GitHub 工具集成的配置:

  1. 从IBM Cloud控制台，单击菜单图标汉堡包图标>平台自动化>工具链。 在“工具链”页面，单击工具链打开其“概述”页面。 或者，在应用程序的“概述”页面的“持续交付”卡片上，单击“查看工具链”>“概述”。

  2. 在“工具链的概述”页面上的 存储库 卡上，找到 GitHub 工具集成。

  3. 单击菜单以访问配置选项并更新配置设置以授权 IBM Cloud 访问 GitHub。

    • 如果选择 OAuth，请单击 授权 以转至 GitHub Web 站点。 如果您没有活动的 GitHub 会话，那么系统会提示您登录。 单击授权IBM，允许IBM Cloud访问您的GitHub账户。
    • 如果选择 Personal Access Token，请为 GitHub提供有效的个人访问令牌。

  4. 完成更新设置时，单击保存集成。

如果要将 Terraform 或 API 与 OAuth 认证方法配合使用，请切换到使用个人访问令牌 (PAT) 向特定用户或存储库提供细粒度访问。 使用 Terraform 或 API 时，建议使用 PAT 进行授权。 否则，您可以使用控制台来授权 IBM Cloud 访问 GitHub 帐户:

  1. 从IBM Cloud控制台，单击菜单图标汉堡包图标>平台自动化>工具链。 在工具链页面，找到要添加GitHub工具集成的工具链。 单击工具链，打开其概述页面。
  2. 在工具链的“概述”页面，单击“添加”。
  3. 在“添加工具集成”页面上，单击 GitHub 工具卡。
  4. 在“配置 GitHub”页面上，单击 授权 以转至 GitHub Web 站点。 如果您没有活动的 GitHub 会话，那么系统会提示您登录。 单击授权IBM，允许IBM Cloud访问您的GitHub账户。 您将被重定向到 "配置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控制台，单击菜单图标汉堡包图标>平台自动化>工具链。 在“工具链”页面，单击要添加此集成的工具链。 或者，在应用程序“概述”页面的“持续交付”卡上，单击查看工具链，然后单击概述。

  2. 单击添加工具。

  3. 在“工具集成”部分中，单击 GitLab。

  4. 单击要使用的 GitLab 服务器。 如果要访问的存储库所在的 GitLab 服务器未显示在此列表中，请添加定制服务器：

    a. 单击自定义服务器。

    b. 输入服务器的名称。 此服务器名称将显示在可用 GitLab 服务器列表中。

    c. 输入定制 GitLab 服务器的根 URL。

    d. 输入定制 GitLab 服务器的个人访问令牌。 如果您没有个人访问令牌，请创建个人访问令牌。

  5. 如果您有 GitLab 存储库并且想要使用该存储库，那么对于存储库类型，请单击现有并输入 URL。

  6. 如果要使用新的 GitLab 存储库，请输入存储库的名称，输入您要克隆或派生的存储库的 URL，然后选择存储库类型：

    a. 要创建空的存储库，请单击新建。

    b. 要创建 GitLab 存储库的副本，请单击克隆。

    c. 要派生 GitLab 存储库以便您可以通过拉出请求来提供更改，请单击派生。

  7. 如果要在服务器上创建公共存储库，请清除使此存储库成为专用复选框。

  8. 如果要使用 GitLab 的 Issues 进行问题跟踪，请选中启用 GitLab Issues 复选框。

  9. 如果要通过在提交上创建标记和注释以及在提交所引用的问题上创建标签和注释来跟踪代码更改的部署，请选中跟踪代码更改的部署复选框。 如需了解更多信息，请参阅 使用工具链跟踪代码的部署位置。

  10. 单击创建集成。

有关配置 GitLab 工具集成的更多信息，请参阅配置 GitLab。

为什么无法通过 HTTPS 来克隆 Git Repos and Issue Tracking 存储库？

您必须使用个人访问令牌或 SSH 密钥才能执行 Git 操作。

您尝试在命令行中使用 HTTPS 来推送或克隆存储库，但尽管您输入了正确的密码，仍无法进行认证。

Git Repos and Issue Tracking 使用单点登录机制，该机制不支持在命令行上使用用户名和密码的 Git 认证。

要执行克隆或推送等 Git 操作，必须使用个人访问令牌或 SSH 密钥。 有关创建个人访问令牌或 SSH 密钥的更多信息，请参阅入门教程。

我尝试使用 SSH 克隆 Git Repos and Issue Tracking 存储库时，为什么会提示我进行认证？

您的专用 SSH 密钥的位置或许可权可能存在问题，或者 Git 命令行可能未使用您的专用 SSH 密钥向 Git Repos and Issue Tracking 进行认证。

我已通过 Git Repos and Issue Tracking 用户界面添加了 SSH 公用密钥。 但在尝试使用 SSH 克隆存储库时，系统提示我输入密码或安全代码，或者显示一条错误消息，指示认证失败。

以下任何 SSH 问题都可能提示您进行认证，或者显示错误消息：

  • Git 命令行可能未使用您的专用 SSH 密钥向 Git Repos and Issue Tracking 进行认证。

  • 您的专用 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 参考文档。

我尝试通过电子邮件向 GitLab 项目添加用户，但用户收不到邀请。 如何将用户添加到项目中？

用户的电子邮件可能阻止了邀请。

我使用 Git Repos and Issue Tracking 中列出的用户电子邮件地址来邀请用户加入 GitLab 项目，但他们未收到该电子邮件。

电子邮件可能被垃圾邮件过滤器阻止进入用户的收件箱中。

可以使用以下任一方法来解决此问题：

  • 检查电子邮件垃圾邮件文件夹，以确定电子邮件邀请是否已标记为垃圾邮件。 电子邮件是从 noreply@ 地址发送的。 请更新垃圾邮件过滤器以允许来自此地址的电子邮件。

  • 调查超出用户控制范围的公司垃圾邮件过滤器是否阻止了该电子邮件。 请要求用户登录到 Git Repos and Issue Tracking 用户界面，并向您发送其用户标识。 您可以使用用户标识将相应用户添加到 GitLab 项目。

当我使用 Terraform 来更新现有 Git 工具集成的配置时，配置为何会失败?

Git 工具集成资源指定 type clone，fork 或 new，并指定现有目标存储库。

使用 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 资源指定 type 为 clone，fork 或 new。 您已将资源的 initialization 块中的 repo_url 更改为存在的存储库的 URL。
  • Git 工具集成 Terraform 资源指定 type 为 clone，fork 或 new。 您未更改 repo_url，但在资源的 initialization 块中更改了一个或多个其他自变量。 在此情况下，存在存储库，因为它是在 Terraform 先前应用 Git 工具集成资源时创建的。

clone，fork 和 new 类型指示 Git 工具集成在此存储库不存在的前提下创建目标存储库 (repo_url)。 如果工具集成找到目标存储库，那么它将因设计而失败。

将 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 操作之间进行手动更改。 如果删除存储库，那么无法撤销删除操作，并且会导致永久数据丢失。