Descripción de las migraciones de GitLab a GitHub

GitHub Enterprise Importer automatiza las migraciones desde GitLab.

Run your migration

Artículo 1 de 7
Siguiente:Planeamiento de la migración de GitLab a GitHub

En este artículo

Acerca de las migraciones desde GitLab

Puede usar GitHub Enterprise Importer para migrar repositorios de GitLab a GitHub Enterprise Cloud (GitHub.com o GHE.com).

Las migraciones se realizan con GL2GH extension of the GitHub CLI, un contenedor de línea de comandos multiplataforma en torno a las GitHub API de migración. Para cada repositorio, :GL2GH extension

  1. Exporta el proyecto de GitLab a un .tar.gz archivo que contiene el repositorio de Git más los metadatos del proyecto (por ejemplo, problemas, solicitudes de combinación, etiquetas, hitos y versiones).
  2. Almacena provisionalmente el archivo localmente en el equipo donde se ejecuta el comando.
  3. Carga el archivo en Blob Storage que GitHub puede leer desde (ya sea GitHub-owned blob storage o desde una cuenta de almacenamiento que posee en AWS S3 o Azure Blob Storage).
  4. Importa el archivo en la organización de destino y transforma las entidades de GitLab en sus GitHub equivalentes.

Antes de crear la cuenta de empresa en GitHub, decida si su empresa usará Enterprise Managed Users. Esto afecta a cómo se autentican los miembros y cómo se administran las identidades y el acceso. Consulte Elección de un tipo de empresa para GitHub Enterprise Cloud.

Versiones admitidas de GitLab

Puede migrar desde GitLab.com e instancias de GitLab autoadministrados.

GitHub Enterprise Importer admite versiones actualmente mantenidas (no de un extremo de vida) de GitLab. Para obtener la lista de versiones mantenidas, consulte Declaración de compatibilidad en la documentación de GitLab. Las versiones anteriores no se han probado ni evaluado.

Datos que se migran

Cuando los datos están presentes en el archivo de exportación de GitLab, GitHub Enterprise Importer migra los siguientes datos de GitLab a GitHub Enterprise Cloud.

  • Origen de Git (incluido el historial de confirmaciones) y la wiki del repositorio
  • Comentarios sobre confirmación de cambios
  • Project configuración que se asigna limpiamente, como la rama predeterminada
  • Problemas y comentarios de problemas, incluidos los eventos de estado e hito del problema
    • Los debates en subprocesos se migran como comentarios planos con contexto del subproceso original
  • Combinar solicitudes, que se convierten en solicitudes de incorporación de cambios, entre las que se incluyen:
    • Comentarios (migrados como comentarios de revisión solo cuando los datos de diferencias están presentes; de lo contrario, como comentarios de problemas planos; solo la diferencia más reciente está presente en la exportación)
    • Revisores y aprobadores
    • Combinar eventos de estado de solicitud
  • Hitos
  • Eventos de escala de tiempo
  • Reacciones de emoji
  • Cargas (datos adjuntos)
  • Versiones y recursos de versión
  • miembros de Project (migrados como maniquíes)

Datos que no se migran

Los datos siguientes no se migran.

  • Git LFS objetos: los archivos de puntero viajan con el historial de Git, pero los objetos binarios se deben insertar en el destino de migración por separado como tarea de seguimiento. Para obtener más información, vea Duplicar un repositorio.
  • Directivas de repositorio, incluidos los trenes de mezcla, las puertas de canalización, las aprobaciones necesarias, los temas, los avatares y la creación de reflejo
  • Configuración de grupo y pertenencia a grupos
  • Fragmentos de código, paneles de problemas, datos de seguimiento de tiempo y datos de administración de diseño
  • Canalizaciones de CI/CD y programaciones de canalización (.gitlab-ci.yml no tiene equivalente automático GitHub Actions )
  • Informes de vulnerabilidades
  • Los datos que GitLab no incluyen en la exportación, como webhooks, variables de CI/CD, seguimientos de trabajos y artefactos, historial de canalización secundario y desencadenadores de canalización

Limitaciones de los datos migrados

Hay límites para lo que GitHub Enterprise Importer puede migrar. Algunos se deben a limitaciones de GitHub, mientras que otros son limitaciones de GitHub Enterprise Importer sí mismos.

Limitaciones de GitHub

  • 2 Límite de tamaño de GiB para una única confirmación de Git: Ninguna confirmación única en el repositorio de Git puede ser superior a 2 GiB. Si alguna de sus confirmaciones supera los 2 GiB, deberá dividir la confirmación en otras más pequeñas, cada una de 2 GiB o menos.
  • Límite de tamaño de 2 GiB para una sola inserción: Ninguna inserción única puede ser mayor que 2 GiB. Las inserciones más grandes producen un pack exceeds maximum allowed size error.
  • Límite de 255 bytes para las referencias de Git: Ninguna referencia de Git única, conocida normalmente como "ref", puede tener un nombre mayor que 255 bytes. Normalmente, esto significa que las referencias no pueden tener más de 255 caracteres, pero cualquier carácter que no sea ASCII, como emojis, puede consumir más de un byte. Si alguna de las referencias de Git es demasiado grande, devolveremos un mensaje de error claro.
  • Límite de tamaño de archivo MiB de 100: Después de completar la migración, ningún archivo único en el repositorio de Git puede ser mayor que 100 MiB. Durante la migración del repositorio, este límite aumenta a 400 MiB. Considere la posibilidad de usar Git LFS para almacenar archivos grandes.

Limitaciones de GitHub Enterprise Importer

  • Límite de tamaño de 40 GB para un repositorio de Git (versión preliminar pública): este límite solo se aplica al código fuente. Para comprobar si el archivo del repositorio supera el límite, use la herramienta git-sizer y revise el tamaño total del blob en la salida. La herramienta git-sizer también ayuda a identificar posibles problemas relacionados con archivos de gran tamaño, tamaño de blob, tamaño de confirmación y recuentos de árboles que podrían afectar a las migraciones.
  • Límite de tamaño de archivo MiB de 400: Al migrar un repositorio con GitHub Enterprise Importer, ningún archivo único en el repositorio de Git puede ser mayor que 400 MiB. Considere la posibilidad de usar Git LFS para almacenar archivos grandes.
  • **Git LFS objetos no migrados:**Importer puede migrar repositorios que usan Git LFS, pero los propios objetos LFS no se migrarán. Se pueden trasladar al destino de la migración como una tarea posterior una vez que se complete la migración.
  • Funcionalidad de búsqueda de código retrasada: volver a indexar el índice de búsqueda puede tardar unas horas después de migrar un repositorio y las búsquedas de código pueden devolver resultados inesperados hasta que se complete la nueva indexación.
  • Los conjuntos de reglas configurados para la organización pueden provocar errores en las migraciones: por ejemplo, si has configurado una regla que requiere que las direcciones de correo electrónico de los creadores de confirmaciones terminen en @monalisa.caty el repositorio que vas a migrar contiene confirmaciones que no cumplen esta regla, se producirá un error en la migración.
  • Es posible que el contenido de Mannequin no se pueda buscar: los maniquíes son usuarios de marcador de posición a los que está asociado el contenido importado (por ejemplo, problemas, solicitudes de incorporación de cambios, comentarios, etc.). Al buscar contenido asociado a un maniquí, como problemas asignados, es posible que no se encuentren los problemas. Una vez reclamado un maniquí, el contenido debe encontrarse a través del nuevo propietario.

Limitaciones de GitLab

  • Límite de 40 GB para el archivo de exportación de GitLab: La API de exportación de proyectos de GitLab no generará un archivo de más de 40 GB en GitLab.com. A diferencia del GitHub límite de tamaño de origen, esto se aplica a todo el archivo de exportación, incluidos los metadatos del proyecto y el origen de Git. GitLab establece este límite y puede diferir en las instancias autoadministradas.