导入和迁移群组及项目

将您现有的工作导入 GitLab 并保留您的贡献历史。 从多个平台整合项目或在 GitLab 实例之间传输数据。

GitLab 提供不同的方法来：

• 使用直接迁移在 GitLab 实例之间复制 GitLab 群组和项目。
• 从各种支持的源导入项目。

使用直接迁移从 GitLab 迁移到 GitLab

在 GitLab 实例之间或同一个 GitLab 实例内复制 GitLab 群组和项目的最佳方式是 使用直接迁移。

另一种选择是使用 群组迁移 来迁移 GitLab 群组。

您还可以使用 GitLab 文件导出复制 GitLab 项目，这是一种支持的导入源。

支持的导入源

默认可用的导入源取决于您使用的 GitLab：

• GitLab.com：所有可用的导入源都默认启用。
• GitLab Self-Managed：没有默认启用的导入源，必须启用。

GitLab 可以从这些支持的导入源导入项目。

开始迁移后，不应在源实例上对导入的群组或项目进行任何更改，因为这些更改可能不会复制到目标实例。

禁用未使用的导入源

仅从您信任的源导入项目。如果从不受信任的源导入项目，攻击者可能会窃取您的敏感数据。例如，带有恶意 .gitlab-ci.yml 文件的导入项目可能允许攻击者窃取群组 CI/CD 变量。

GitLab Self-管理员可以通过禁用不需要的导入源来减少攻击面：

1. 在左侧边栏底部，选择 Admin。
2. 选择 Settings > General。
3. 展开 Import and export settings。
4. 滚动到 Import sources。
5. 清除不需要的导入器的复选框。

其他导入源

您还可以阅读有关从这些其他导入源导入的信息：

• ClearCase
• 并发版本系统 (CVS)
• Jira（仅问题）
• Perforce Helix
• Team Foundation 版本控制 (TFVC)

从 Subversion 导入仓库

GitLab 无法自动将 Subversion 仓库迁移到 Git。将 Subversion 仓库转换为 Git 可能很困难，但存在多种工具，包括：

• git svn，适用于非常小和基础的仓库。
• reposurgeon，适用于更大和更复杂的仓库。

用户贡献和成员映射

这种用户贡献和成员映射方法默认适用于 直接迁移、GitHub 导入器、 Bitbucket Server 导入器 和 Gitea 导入器 在 GitLab.com 和 GitLab Self-Managed 上。 有关 GitLab Self-Managed 在禁用功能标志时可用的另一种方法的信息， 请参阅每个导入器的文档。

您导入的所有成员资格和贡献首先映射到占位符用户。 这些占位符在目标实例上创建，即使源实例上存在具有相同电子邮件地址的用户。 在您重新分配目标实例上的贡献之前， 所有贡献都显示为与占位符关联。

导入完成后，您可以：

• 在查看结果后，将成员资格和贡献重新分配给目标实例上的现有用户。 您可以为源实例和目标实例上具有不同电子邮件地址的用户映射成员资格和贡献。
• 在目标实例上创建新用户以重新分配成员资格和贡献。

当您将贡献重新分配给目标实例上的用户时，用户可以 接受 或 拒绝 重新分配。 当用户接受重新分配时：

• 贡献被重新分配。此过程可能需要几分钟时间。
• 在后续从同一源实例到同一顶级群组或子群组的导入中， 贡献会自动映射到该用户。

在 GitLab 18.0 及更高版本中，如果您的顶级群组 至少有一个企业用户，您只能在 UI 中或通过 CSV 文件 将贡献重新分配给您组织中的企业用户。 此功能旨在防止意外重新分配给您组织外的用户。

要求

• 您必须能够创建足够的用户，受限于用户限制。
• 如果您导入到 GitLab.com，必须在导入前设置您的付费命名空间。
• 如果您导入到 GitLab.com 并使用 GitLab.com 群组的 SAML SSO， 所有用户必须将他们的 SAML 身份链接到他们的 GitLab.com 账户，然后您才能 重新分配贡献和成员资格。

占位符用户

没有立即将贡献和成员资格分配给目标实例上的用户，而是为任何具有导入贡献或成员资格的活动、非活动或机器人用户创建占位符用户。 对于源实例上的已删除用户，创建的占位符不包含所有占位符用户属性。 您应该将这些用户保持为占位符。 有关更多信息，请参阅 issue 506432。

贡献和成员资格首先分配给这些占位符用户，导入后可以重新分配给目标实例上的现有用户。 在重新分配之前，贡献显示为与占位符关联。占位符成员资格 不会显示在成员列表中。

占位符用户不计入许可证限制。

异常情况

为源实例上的每个用户创建占位符用户，但以下情况除外：

• 您正在从 Gitea 导入项目，并且该用户在导入前已在 Gitea 上被删除。 这些用户的贡献映射到导入项目的用户，而不是占位符用户。
• 您已超过您的占位符用户限制。超出限制后任何新用户的贡献 映射到一个名为 Import User 的非功能性用户。
• 您正在导入到个人命名空间。 贡献分配给一个名为 Import User 的非功能性用户。 Issue 525342 建议将所有贡献映射到导入用户。

占位符用户属性

占位符用户与常规用户不同，不能：

• 登录。
• 执行任何操作。例如，运行流水线。
• 作为问题或合并请求的指派人或审查者出现在建议中。
• 成为项目和群组的成员。

为了与源实例上的用户保持连接，占位符用户具有：

• 一个唯一标识符 (source_user_id)，导入过程使用它来确定是否需要新的占位符用户。
• 源主机名或域名 (source_hostname)。
• 源用户的名称 (source_name) 以帮助重新分配贡献。
• 源用户名 (source_username) 以在贡献重新分配期间促进群组所有者。
• 导入类型 (import_type) 以区分哪个导入器创建了占位符。
• 源用户创建时间的时间戳 (`created_at)，以本地时间用于迁移跟踪 (在 GitLab 17.10 中引入)。

为了保留历史上下文，占位符用户名和用户名源自源用户名和用户名：

• 占位符用户的名称为 Placeholder <source user name>。
• 占位符用户名为 %{source_username}_placeholder_user_%{incremental_number}。

查看占位符用户

先决条件：

• 您必须拥有群组的 Owner 角色。

占位符用户在群组或项目导入时在目标实例上创建。 要查看导入到顶级群组及其子群组的占位符用户：

1. 在左侧边栏，选择 Search or go to 并找到您的群组。 此群组必须是顶级群组。
2. 选择 Manage > Members。
3. 选择 Placeholders 标签页。

过滤占位符用户

先决条件：

• 您必须具有实例的管理员访问权限。

占位符用户在群组或项目导入时在目标实例上创建。 要过滤整个实例导入期间创建的占位符用户：

1. 在左侧边栏底部，选择 Admin。
2. 选择 Overview > Users。
3. 在搜索框中，按 type 过滤用户。

创建占位符用户

占位符用户按导入源和顶级群组创建：

• 如果您将同一项目两次导入到目标实例的同一顶级群组，第二次导入使用 与第一次导入相同的占位符用户。
• 如果您将同一项目两次导入，但导入到目标实例的不同顶级群组，第二次导入 在该顶级群组下创建新的占位符用户。

当用户接受重新分配时， 后续从同一源实例到同一顶级群组或子群组的导入不会创建占位符用户。 相反，贡献会自动映射到该用户。

占位符用户删除

当您删除包含占位符用户的顶级群组时，这些占位符用户会 自动删除。但是，如果占位符用户还与已删除顶级群组之外的项目或群组关联， 它们将保留在系统中。

占位符用户限制

如果导入到 GitLab.com，占位符用户在目标实例的每个顶级群组上有限制。限制取决于您的计划和座位数。占位符用户不计入许可证限制。

对于 GitLab Self-Managed 和 GitLab Dedicated，默认不应用占位符限制。 GitLab 管理员可以在其实例上设置占位符限制。

要查看您当前的占位符用户使用情况和限制：

1. 在左侧边栏，选择 Search or go to 并 找到您的群组。此群组必须是顶级群组。
2. 选择 Settings > Usage quotas。
3. 选择 Import 标签页。

您无法提前确定需要的占位符用户数量。

当达到占位符用户限制时，所有贡献 都分配给一个名为 Import User 的非功能性用户。 分配给 Import User 的贡献可能会被去重， 一些贡献可能在导入期间未创建。 例如，如果来自合并请求审批者的多个批准分配给 Import User，只创建第一个批准，其他被忽略。 可能被去重的贡献包括：

• 审批规则
• Emoji 反应
• 问题指派人
• 成员资格
• 合并请求批准、指派人和审查者
• 推送、合并请求和部署访问级别

每次更改都会创建系统注释，不受占位符用户限制影响。

重新分配贡献和成员资格

拥有顶级群组 Owner 角色的用户可以将贡献和成员资格 从占位符用户重新分配给现有的活动非机器人用户。 在目标实例上，拥有顶级群组 Owner 角色的用户可以：

• 在 UI 中请求用户审查贡献和成员资格的重新分配 或通过 CSV 文件。 对于大量占位符用户，您应该使用 CSV 文件。 在这两种情况下，用户都会收到电子邮件请求以接受或拒绝重新分配。 只有在所选用户接受重新分配请求后， 重新分配才会开始。
• 选择不重新分配贡献和成员资格，并将它们保留分配给占位符用户。

在 GitLab Self-Managed 和 GitLab Dedicated 上，管理员可以立即重新分配 贡献和成员资格给活动和非活动非机器人用户，无需其确认。 有关更多信息，请参阅管理员重新分配占位符用户时跳过确认。

从多个占位符用户重新分配贡献

最初分配给单个占位符用户的所有贡献只能重新分配给目标实例上的单个活动常规用户。 分配给单个占位符用户的贡献不能分割给多个活动常规用户。

如果占位符用户来自以下情况，您可以将多个占位符用户的贡献重新分配给目标实例上的同一用户：

• 不同的源实例
• 相同的源实例并导入到目标实例的不同顶级群组

如果分配的用户在接受重新分配请求之前变为非活动状态， 待处理的重新分配仍然与该用户关联，直到他们接受为止。

源实例上的机器人用户贡献和成员资格不能重新分配给目标实例上的机器人用户。 您可能选择将源机器人用户贡献保留分配给占位符用户。

收到重新分配请求的用户可以：

• 接受请求。先前归因于占位符用户的所有贡献和成员资格重新归因于 接受的用户。此过程可能需要几分钟时间，具体取决于贡献数量。
• 拒绝请求 或将其报告为垃圾邮件。此选项在重新分配 请求电子邮件中可用。

在后续导入到同一顶级群组时，属于同一源用户的贡献和成员资格会自动映射到 先前接受该源用户重新分配的用户。

在 GitLab Self-Managed 和 GitLab Dedicated 上，管理员可以立即重新分配 贡献和成员资格给活动和非活动非机器人用户，无需其确认。 有关更多信息，请参阅管理员重新分配占位符用户时跳过确认。

完成重新分配

在您执行以下操作之前，必须完全完成重新分配过程：

• 在同一 GitLab 实例中移动导入的群组。
• 将导入的项目移动到不同的群组。
• 复制导入的问题。
• 将导入的问题提升为史诗。

如果过程未完成，仍然分配给占位符用户的贡献无法重新分配给真实用户， 它们仍然与占位符用户关联。

安全考虑

贡献和成员资格的重新分配无法撤销，因此在开始前请仔细检查一切。

将贡献和成员资格重新分配给不正确的用户会带来安全威胁，因为该用户成为您的群组成员。 因此，他们可以查看他们不应看到的信息。

重新分配贡献给具有管理员访问权限的用户默认是禁用的，但您可以 启用它。

成员资格安全考虑

由于 GitLab 权限模型，当群组或项目导入到现有父群组时，父群组的成员被授予 导入群组或项目的继承成员资格。

为贡献和成员资格重新分配选择一个已经具有 导入群组或项目现有继承成员资格的用户可能会影响成员资格如何重新分配给他们。

GitLab 不允许子项目或子群组的成员资格具有比继承成员资格更低的角色。 如果分配用户的导入成员资格低于其现有继承成员资格，则导入的成员资格不会重新分配给该用户。

这导致他们对导入群组或项目的成员资格高于源实例上的成员资格。

在 UI 中请求重新分配

先决条件：

• 您必须拥有群组的 Owner 角色。

您可以在顶级群组中重新分配贡献和成员资格。 要请求贡献和成员资格的重新分配：

1. 在左侧边栏，选择 Search or go to 并找到您的群组。 此群组必须是顶级群组。
2. 选择 Manage > Members。
3. 选择 Placeholders 标签页。
4. 转到 Awaiting reassignment 子标签页，其中占位符在表格中列出。
5. 对于每个占位符，查看表格列 Placeholder user 和 Source 中的信息。
6. 在 Reassign placeholder to 列中，从下拉列表中选择一个用户。
7. 选择 Reassign。

只能将一个占位符用户的贡献重新分配给目标实例上的一个活动非机器人用户。

在用户接受重新分配之前，您可以取消请求。

在 GitLab Self-Managed 和 GitLab Dedicated 上，管理员可以立即重新分配 贡献和成员资格给活动和非活动非机器人用户，无需其确认。 有关更多信息，请参阅管理员重新分配占位符用户时跳过确认。

通过 CSV 文件请求重新分配

先决条件：

• 您必须拥有群组的 Owner 角色。

对于大量占位符用户，您可能希望 通过 CSV 文件重新分配贡献和成员资格。 您可以下载包含以下信息的预填充 CSV 模板。 例如：

不要更新 Source host、Import type 或 Source user identifier。 此信息在您上传完成的 CSV 文件后用于定位相应的数据库记录。 Source user name 和 Source username 标识源用户， 在您上传 CSV 文件后不使用。

您不必更新 CSV 文件的每一行。 只有 GitLab username 或 GitLab public email 的行才会被处理。 所有其他行都将被跳过。

要通过 CSV 文件请求贡献和成员资格的重新分配：

1. 在左侧边栏，选择 Search or go to 并找到您的群组。
2. 选择 Manage > Members。
3. 选择 Placeholders 标签页。
4. 选择 Reassign with CSV。
5. 下载预填充的 CSV 模板。
6. 在 GitLab username 或 GitLab public email 中，输入 目标实例上 GitLab 用户的用户名或公开电子邮件地址。 实例管理员可以重新分配任何已确认电子邮件地址的用户。
7. 上传完成的 CSV 文件。
8. 选择 Reassign。

您只能将来自单个占位符用户的贡献 分配给目标实例上的每个活动非机器人用户。 用户会收到电子邮件以审查和接受您重新分配给他们的任何贡献。 您可以在用户审查之前取消重新分配请求。

在 GitLab Self-Managed 和 GitLab Dedicated 上，管理员可以立即重新分配 贡献和成员资格给活动和非活动非机器人用户，无需其确认。 有关更多信息，请参阅管理员重新分配占位符用户时跳过确认。

重新分配贡献后，GitLab 会向您发送包含以下数量的电子邮件：

• 成功处理的行数
• 未成功处理的行数
• 跳过的行数

如果有任何行未成功处理，电子邮件将包含包含更详细结果的 CSV 文件。

要批量重新分配占位符用户而不使用 UI， 请参阅群组占位符重新分配 API。

保持为占位符

您可能不想将贡献和成员资格重新分配给目标实例上的用户。例如，您 可能有在源实例上做出贡献的前员工，但他们作为用户不存在于目标实例上。

在这些情况下，您可以将贡献保留分配给占位符用户。占位符用户不保留 成员资格信息，因为它们不能成为项目或群组的成员。

由于占位符用户的姓名和用户名类似于源用户的姓名和用户名，您保留了大量 历史上下文。

请记住，如果您将剩余的占位符用户保持为占位符，您以后无法将它们的贡献重新分配给 实际用户。在将剩余的占位符用户保持为占位符之前，请确保完成所有必需的重新分配。

您可以一次或批量保持贡献分配给占位符用户。 当您批量重新分配贡献时，整个命名空间和具有以下 重新分配状态 的用户都会受到影响：

• Not started
• Rejected

一次保持占位符用户：

1. 在左侧边栏，选择 Search or go to 并找到您的群组。 此群组必须是顶级群组。
2. 选择 Manage > Members。
3. 选择 Placeholders 标签页。
4. 转到 Awaiting reassignment 子标签页，其中占位符在表格中列出。
5. 通过查看 Placeholder user 和 Source 列找到您想要保持的占位符用户。
6. 在 Reassign placeholder to 列中，选择 Do not reassign。
7. 选择 Confirm。

批量保持占位符用户：

1. 在左侧边栏，选择 Search or go to 并找到您的群组。 此群组必须是顶级群组。
2. 选择 Manage > Members。
3. 选择 Placeholders 标签页。
4. 在列表上方，选择垂直省略号 ( ) > Keep all as placeholders。
5. 在确认对话框中，选择 Confirm。

取消重新分配请求

在用户接受重新分配请求之前，您可以取消请求：

1. 在左侧边栏，选择 Search or go to 并找到您的群组。 此群组必须是顶级群组。
2. 选择 Manage > Members。
3. 选择 Placeholders 标签页。
4. 转到 Awaiting reassignment 子标签页，其中占位符在表格中列出。
5. 在正确的行中选择 Cancel。

再次通知用户待处理的重新分配请求

如果用户没有对重新分配请求采取行动，您可以通过发送另一封电子邮件来提醒他们：

1. 在左侧边栏，选择 Search or go to 并找到您的群组。 此群组必须是顶级群组。
2. 选择 Manage > Members。
3. 选择 Placeholders 标签页。
4. 转到 Awaiting reassignment 子标签页，其中占位符在表格中列出。
5. 在正确的行中选择 Notify。

按重新分配状态查看和过滤

要查看所有占位符用户的重新分配状态：

1. 在左侧边栏，选择 Search or go to 并找到您的群组。 此群组必须是顶级群组。
2. 选择 Manage > Members。
3. 选择 Placeholders 标签页。
4. 转到 Awaiting reassignment 子标签页，其中占位符在表格中列出。
5. 在 Reassignment status 列中查看每个占位符用户的状态。

在 Awaiting reassignment 标签页中，可能的状态有：

• Not started - 重新分配尚未开始。
• Pending approval - 重新分配等待用户批准。
• Reassigning - 重新分配正在进行中。
• Rejected - 重新分配被用户拒绝。
• Failed - 重新分配失败。

在 Reassigned 标签页中，可能的状态有：

• Success - 重新分配成功。
• Kept as placeholder - 占位符用户被永久保留。

默认情况下，表格按占位符用户名按字母顺序排序。 您也可以按重新分配状态对表格进行排序。

确认贡献重新分配

当管理员重新分配占位符用户时跳过确认 启用时：

• 管理员可以立即重新分配贡献，无需用户确认。
• 管理员可以重新分配贡献给活动和非活动非机器人用户。
• 您会收到一封电子邮件，通知您您已被重新分配贡献。

如果未启用此设置，您可以接受 或拒绝重新分配。

接受贡献重新分配

您可能会收到一封电子邮件，告知您导入过程已完成，并要求您确认将贡献重新分配给您自己。

如果您收到有关此导入过程的通知，您仍然必须非常仔细地审查重新分配详细信息。电子邮件中列出的详细信息包括：

• Imported from - 导入内容的来源平台。例如，另一个 GitLab 实例、GitHub 或 Bitbucket。
• Original user - 源平台上用户的姓名和用户名。这可能是您在该平台上的姓名和用户名。
• Imported to - 新平台的名称，只能是 GitLab 实例。
• Reassigned to - 您在 GitLab 实例上的全名和用户名。
• Reassigned by - 执行导入的同事或经理的全名和用户名。

拒绝贡献重新分配

如果您收到一封电子邮件，要求您确认将贡献重新分配给您自己，并且您不认识或注意到此信息中的错误：

1. 不要继续操作或拒绝贡献重新分配。
2. 与值得信赖的同事或经理交谈。

安全考虑

您必须非常仔细地审查任何重新分配请求的重新分配详细信息。如果您尚未通过值得信赖的同事或经理了解此过程，请格外小心。

对于您有任何疑虑的任何重新分配，不要接受：

1. 不要对电子邮件采取行动。
2. 与值得信赖的同事或经理交谈。

仅接受您认识并信任的用户的重新分配。贡献的重新分配是永久性的，无法撤销。 接受重新分配可能导致贡献被错误地归因于您。

贡献重新分配过程仅在您通过在 GitLab 中选择 Approve reassignment 来接受重新分配请求后才开始。 通过选择电子邮件中的链接不会开始此过程。

查看项目导入历史

您可以查看您创建的所有项目导入。此列表包括以下内容：

• 如果项目是从外部系统导入的，则为源项目的路径；如果是 GitLab 项目迁移的，则为导入方法。
• 目标项目的路径。
• 每个导入的开始日期。
• 每个导入的状态。
• 如果发生任何错误，则为错误详细信息。

要查看项目导入历史：

1. 登录 GitLab。
2. 在左侧边栏顶部，选择 Create new ( ) 和 New project/repository。
3. 选择 Import project。
4. 在右上角，选择 History 链接。
5. 如果特定导入有任何错误，选择 Details 查看它们。

历史记录还包括从内置 或自定义 模板创建的项目。GitLab 使用通过 URL 导入仓库 从模板创建新项目。

导入包含 LFS 对象的项目

当导入包含 LFS 对象的项目时，如果项目具有一个 .lfsconfig 文件，其中 URL 主机 (lfs.url) 与仓库 URL 主机不同，则不会下载 LFS 文件。

通过参与专业服务进行迁移

如果您愿意，可以参与 GitLab 专业服务将群组和项目迁移到 GitLab，而不是自己进行。有关更多信息，请参阅专业服务完整目录。

Sidekiq 配置

导入器严重依赖 Sidekiq 作业来处理群组和项目的导入和导出。 其中一些作业可能消耗大量资源（CPU 和内存）， 并且需要很长时间才能完成，这可能会影响其他作业的执行。 为了解决这个问题，您应该将导入器作业路由到专用的 Sidekiq 队列， 并分配专用的 Sidekiq 进程来处理该队列。

例如，您可以使用以下配置：

sidekiq['concurrency'] = 20

sidekiq['routing_rules'] = [
  # 将导入和导出作业路由到导入器队列
  ['feature_category=importers', 'importers'],

  # 使用通配符匹配将所有其他作业路由到默认队列
  ['*', 'default']
]

sidekiq['queue_groups'] = [
  # 为导入器队列运行专用进程
  'importers',

  # 为默认和邮件队列运行单独的进程
  'default,mailers'
]

在此设置中：

• 专用的 Sidekiq 进程通过导入器队列处理导入和导出作业。
• 另一个 Sidekiq 进程处理所有其他作业（默认和邮件队列）。
• 两个 Sidekiq 进程都配置为默认运行 20 个并发线程。 对于内存受限的环境，您可能希望减少此数量。

如果您的实例有足够的资源来支持更多并发作业， 您可以配置额外的 Sidekiq 进程来加速迁移。 例如：

sidekiq['queue_groups'] = [
  # 为导入器作业运行三个进程
  'importers',
  'importers',
  'importers',

  # 为默认和邮件队列运行单独的进程
  'default,mailers'
]

在此设置中，多个 Sidekiq 进程并发处理导入和导出作业， 只要实例有足够的资源，就会加速迁移。

对于最大 Sidekiq 进程数，请记住以下几点：

• 进程数不应超过可用的 CPU 内核数。
• 每个进程最多可使用 2 GB 内存，因此确保实例 有足够的内存用于任何额外的进程。
• 每个进程根据 sidekiq['concurrency'] 中的定义， 每个线程添加一个数据库连接。

有关更多信息，请参阅运行多个 Sidekiq 进程 和处理特定作业类。

故障排除

导入的仓库缺少分支

如果导入的仓库不包含源仓库的所有分支：

1. 设置环境变量 IMPORT_DEBUG=true。
2. 使用不同的群组、子群组或项目名称重试导入。
3. 如果仍然缺少某些分支，检查 importer.log （例如，使用 jq）。

异常：Error Importing repository - No such file or directory @ rb_sysopen - (filename)

如果您尝试导入仓库源代码的 tar.gz 文件下载，会发生此错误。

导入需要 GitLab 导出 文件，而不仅仅是仓库下载文件。

诊断长时间或失败的导入

如果您在使用 S3 的基于文件的导入中遇到长时间延迟或故障，以下可能有助于识别问题的根本原因：

• 检查导入步骤
• 审查日志
• 识别常见问题

检查导入状态

检查导入状态：

1. 使用 GitLab API 检查受影响项目的导入状态。
2. 查看响应中的任何错误消息或状态信息，特别是 status 和 import_error 值。
3. 记录响应中的 correlation_id，这对进一步故障排除至关重要。

审查日志

搜索相关日志信息：

对于 GitLab Self-Managed 实例：

1. 检查 Sidekiq 日志 和 exceptions_json 日志。
2. 搜索与 RepositoryImportWorker 和来自检查导入状态的 correlation ID 相关的条目。
3. 查找诸如 job_status、interrupted_count 和 exception 之类的字段。

对于 GitLab.com（仅限 GitLab 团队成员）：

1. 使用 Kibana 搜索 Sidekiq 日志，查询如下：

   目标：pubsub-sidekiq-inf-gprd*

   json.class: "RepositoryImportWorker" AND json.correlation_id.keyword: "<CORRELATION_ID>"

   或

   json.class: "RepositoryImportWorker" AND json.meta.project: "<project.full_path>"

2. 查看与 GitLab Self-Managed 实例相同的字段。

识别常见问题

根据审查日志中收集的信息检查以下常见问题：

• 中断的作业：如果您看到高 interrupted_count 或指示失败的 job_status，导入作业可能已被中断多次并放置在死队列中。
• S3 连接性：对于使用 S3 的导入，检查日志中是否有任何 S3 相关的错误消息。
• 大型仓库：如果仓库非常大，导入可能会超时。在这种情况下，考虑使用直接迁移。