Migración de repositorios desde GitHub Enterprise Server a GitHub Enterprise Cloud

Si decides usar la API, tendrás que escribir scripts propios, o bien usar un cliente HTTP como Insomnia. Puedes obtener más información sobre cómo empezar a trabajar con las API de GitHub en Introducción a la API REST y Formar llamados con GraphQl.

Para migrar los repositorios desde GitHub Enterprise Server a GitHub Enterprise Cloud con las API, haz lo siguiente:

1. Crea una instancia de personal access token para la organización de origen y de destino
2. Captura el valor ownerId de la organización de destino en GitHub Enterprise Cloud
3. Configure un origen de migración mediante GraphQL API de GitHub para identificar desde dónde se va a realizar la migración.
4. Para cada repositorio que quieras migrar, repite estos pasos.
   • Usa la API REST en tu instancia de GitHub Enterprise Server a fin de generar archivos de migración para el repositorio
   • Cargue los archivos de migración en una ubicación accesible para GitHub
   • Inicia la migración con la API GraphQL de tu destino de migración y pasa las URL de los archivos.
   • Comprueba el estado de la migración mediante GraphQL API
   • Valida la migración y comprueba el registro de errores

Para ver instrucciones de uso de la GitHub CLI, usa el conmutador de herramientas en la parte superior de la página.

Paso 1. Creación de personal access token

1. Crea y registra una instancia de personal access token (classic) que se autenticará para la organización de destino en GitHub Enterprise Cloud, y asegúrate de que el token cumple todos los requisitos. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».
2. Crea y registra una instancia de personal access token que se autenticará para la organización de origen, y asegúrate de que este token también cumple todos los mismos requisitos.

Paso 2: Obtención de ownerId la organización de destino

Como propietario de la organización en GitHub Enterprise Cloud, usa la consulta GetOrgInfo para devolver ownerId, también denomino id. de organización, para la organización que quieras que posea los repositorios migrados. Necesitarás el valor ownerId para identificar el destino de la migración.

Consulta GetOrgInfo

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}

Respuesta GetOrgInfo

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

En este ejemplo, MDEyOk9yZ2FuaXphdGlvbjU2MTA= es el id. de la organización o ownerId, que se usará en el paso siguiente.

Paso 3: Configuración del almacenamiento de blobs

Como muchas instancias de GitHub Enterprise Server se encuentran detrás de firewalls, para las versiones de GitHub Enterprise Server 3.8 o superiores, se usa el almacenamiento de blobs como una ubicación intermedia para almacenar los datos a los que GitHub puede acceder.

Primero debes configurar el almacenamiento de blobs con un proveedor de nube compatible y, después, configurar los valores en la Consola de administración de tu instancia de GitHub Enterprise Server.

Configuración del almacenamiento de blobs con un proveedor de nube compatible

La GitHub CLI admite los siguientes proveedores de almacenamiento de blobs:

• Amazon Web Services (AWS) S3
• Azure Blob Storage

Configuración de un cubo de almacenamiento de AWS S3

En AWS, configura un cubo S3. Para más información, consulta Creación de un cubo en la documentación de AWS.

También necesitará una clave de acceso de AWS y una clave secreta con los siguientes permisos:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::github-migration-bucket",
                "arn:aws:s3:::github-migration-bucket/*"
            ]
        }
    ]
}

Configuración de una cuenta de Azure Blob Storage

En Azure, crea una cuenta de almacenamiento y anota la cadena de conexión. Para más información, consulta Administración de las claves de acceso de la cuenta de almacenamiento en Microsoft Docs.

Configuración del almacenamiento de blobs en la Consola de administración de tu instancia de GitHub Enterprise Server

Después de configurar un depósito de almacenamiento de AWS S3 o una cuenta de almacenamiento de Azure Blob Storage, configura el almacenamiento de blobs en la Consola de administración de tu instancia de GitHub Enterprise Server. Para más información sobre la Consola de administración, consulta "Administración de la instancia desde la consola de administración".

1. Desde una cuenta administrativa de GitHub Enterprise Server, en la esquina superior derecha de cualquier página, haz clic en .

2. Si todavía no estás en la página "Administrador del sitio", en la esquina superior izquierda, haz clic en Administrador del sitio. 1. En la barra lateral " Administrador del sitio", haz clic en Consola de administración .

3. Inicia sesión en la Consola de administración.

4. En la barra de navegación superior, haz clic en Configuración.

5. En Migraciones, haz clic en Habilitar migraciones de GitHub .

6. Opcionalmente, para importar los valores de almacenamiento que has configurado para GitHub Actions, selecciona Copiar configuración de almacenamiento desde Acciones. Para más información, consulta "Habilitación de Acciones de GitHub con Azure Blob Storage" y "Habilitación de Acciones de GitHub con el almacenamiento de Amazon S3".

   Note

   Después de copiar la configuración de almacenamiento, es posible que tengas que actualizar la configuración de la cuenta de almacenamiento de nube para trabajar con GitHub Enterprise Importer. En concreto, debe asegurarse de que las direcciones IP de GitHub están agregadas a la lista de permitidas. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».

7. Si no importas la configuración de almacenamiento de GitHub Actions, selecciona Azure Blob Storage o Amazon S3, y rellene los detalles necesarios.

   Note

   Si usas Amazon S3, debes establecer "AWS Service URL" en el punto de conexión estándar de la región de AWS donde se encuentra el cubo. Por ejemplo, si el cubo se encuentra en la región eu-west-1, la "URL del servicio de AWS" sería https://s3.eu-west-1.amazonaws.com. Los datos GitHub Enterprise Server de la red de instancia deben permitir el acceso a este host. No se admiten puntos de conexión de puerta de enlace, como bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com. Para obtener más información sobre los puntos de conexión de puerta de enlace, consulta Puntos de conexión de puerta de enlace para Amazon S3 en la documentación de AWS.

8. Haz clic en Probar configuración de almacenamiento.

9. Haga clic en Save settings (Guardar configuración).

Permiso para el acceso a la red

Si has configurado reglas de firewall en la cuenta de almacenamiento, asegúrate de que has permitido el acceso a los intervalos IP para el destino de la migración. Consulta Administración del acceso para una migración entre productos de GitHub.

Paso 4: Configuración de un origen de migración en GitHub Enterprise Cloud

Puedes configurar un origen de migración mediante la consulta createMigrationSource. Tendrás que proporcionar el valor ownerId, o id. de organización, recopilado de la consulta GetOrgInfo.

El origen de migración es la organización en GitHub Enterprise Server.

Mutación createMigrationSource

mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

Respuesta createMigrationSource

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ",
        "name": "GHES Source",
        "url": "https://my-ghes-hostname.com",
        "type": "GITHUB_ARCHIVE"
      }
    }
  }
}

En este ejemplo, MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ es el identificador de origen de la migración, que se usará en un paso posterior.

Paso 5: Generación de archivos de migración en tu instancia de GitHub Enterprise Server

Utilice la API de REST para iniciar dos "migraciones" en GitHub Enterprise Server: una para generar un archivo del origen de Git del repositorio, y otra para generar un archivo de los metadatos del repositorio (por ejemplo, las incidencias y las solicitudes de incorporación de cambios).

Para generar el archivo de origen de Git, realiza una solicitud POST a https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations, y reemplaza HOSTNAME por el nombre de host de tu instancia de GitHub Enterprise Server y ORGANIZATION por el inicio de sesión de la organización.

En el cuerpo, especifica el único repositorio que quieras migrar. La solicitud será similar a esta:

POST /api/v3/orgs/acme-corp/migrations HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Content-Type: application/json
Host: github.acmecorp.net

{
  "repositories": ["repository_to_migrate"],
  "exclude_metadata": true
}

Para generar el archivo de metadatos, envía una solicitud similar a la misma dirección URL con el siguiente cuerpo:

{
  "repositories": ["repository_to_migrate"],
  "exclude_git_data": true,
  "exclude_releases": false,
  "exclude_owner_projects": true
}

Cada una de estas dos llamadas API devolverá una respuesta JSON, incluido el identificador de la migración que ha iniciado.

HTTP/1.1 201 Created

{
  "id": 123,
  // ...
}

Para obtener más información, consulta Iniciar una migración de la organización.

La generación de los archivos puede tardar un tiempo, en función de la cantidad de datos. Puede comprobar periódicamente el estado de las dos migraciones con la API "Obtener un estado de migración de la organización" hasta que el valor state de la migración cambie a exported.

GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "state": "exported",
  // ...
}

Para obtener más información, consulta Obtener un estado de migración de la organización.

Después de que el valor state de una migración se mueva a exported, puede capturar la dirección URL de la migración mediante la API "Descargar un archivo de migración de la organización".

GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 302 Found
Location: https://media.github.acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6

La API devolverá una respuesta 302 Found con un encabezado Location que redirige a la dirección URL donde se encuentra el archivo descargable. Descarga los dos archivos: uno para el origen de Git y otro para los metadatos.

Para obtener más información, consulta Descargar un archivo de migración de la organización.

Después de que se hayan completado las dos migraciones y haya descargado los archivos, puede pasar al paso siguiente.

Paso 6: Carga de los archivos de migración

Para importar los datos en GitHub Enterprise Cloud, tiene que pasar los dos archivos para cada repositorio (origen de Git y metadatos) desde la máquina a GitHub mediante GraphQL API.

Si usa GitHub Enterprise Server 3,7 o una versión anterior, primero debe generar direcciones URL para los archivos a los que accederá GitHub. La mayoría de los clientes eligen cargar los archivos en el servicio de almacenamiento de blobs de un proveedor de nube, como Amazon S3 o Azure Blob Storage, y luego generar una dirección URL de corta duración para cada uno.

Si usas GitHub Enterprise Server 3.8 o una versión superior, la instancia carga los archivos y genera las direcciones URL automáticamente. El encabezado Location del paso anterior devolverá la dirección URL de corta duración.

Es posible que tengas que permitir intervalos IP deGitHub. Para más información, consulta Administración del acceso para una migración entre productos de GitHub.

Paso 7: Inicio de la migración del repositorio

Al iniciar una migración, un único repositorio y sus datos adjuntos se migran a un repositorio nuevo de GitHub que identifiques.

Si quieres mover varios repositorios a la vez desde la misma organización de origen, puedes poner en cola varias migraciones. Puedes ejecutar hasta cinco migraciones de repositorio a la vez.

Mutación startRepositoryMigration

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $gitArchiveUrl: String!,
  $metadataArchiveUrl: String!,
  $sourceRepositoryUrl: URI!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    gitArchiveUrl: $gitArchiveUrl,
    metadataArchiveUrl: $metadataArchiveUrl,
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}

Para obtener los requisitos de personal access token, consulta Administración del acceso para una migración entre productos de GitHub.

En el paso siguiente, usarás el id. de migración devuelto por la mutación startRepositoryMigration para comprobar el estado de la migración.

Paso 8: Comprobación del estado de la migración

Para detectar errores de migración y asegurarse de que la migración funciona, puedes comprobar el estado de la migración mediante la consulta getMigration. También puedes comprobar el estado de varias migraciones con getMigrations.

La consulta getMigration devolverá con un estado para que sepas si la migración es queued, in progress, failed o completed. Si se ha producido un error en la migración, en Importer se proporcionará un motivo para el error.

Consulta getMigration

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}

Paso 9: Validación de la migración y comprobación del registro de errores

Para finalizar la migración, se recomienda comprobar la incidencia "Registro de migración". Esta incidencia se crea en GitHub en el repositorio de destino.

Por último, se recomienda revisar los repositorios migrados para obtener una comprobación de solidez.