Migración del repositorio con Enterprise Live Migrations

Prerequisites

Asegúrese de que los entornos y desarrolladores están listos para la migración. Consulte Preparación para la migración en vivo desde GitHub Enterprise Server a GHE.com.

1. Configurar GitHub Enterprise Server

Debe establecer alguna configuración en la GitHub Enterprise Server instancia antes de crear tokens y realizar una migración. Estos valores de configuración se aplican a todas las ELM migraciones. GitHub Enterprise Server Los desarrolladores pueden experimentar un breve tiempo de inactividad al aplicar la nueva configuración.

1. Acceda al GitHub Enterprise Server shell administrativo mediante SSH. Consulte Acceder al shell administrativo (SSH).

2. Establezca las siguientes variables de configuración con ghe-config.

   Por ejemplo: ghe-config app.elm-exporter.enabled true

   Variable	Establézcalo en...
   app.elm-exporter.enabled	true
   app.elm.internal-webhooks-enabled	true
   app.elm-exporter.webhooks-loopback-address-enabled	true
   secrets.elm-exporter.migration-target-url	La dirección URL de API de la empresa de destino (por ejemplo: https://api.octocorp.ghe.com).

No incluya una barra diagonal final al final de la dirección URL. | | secrets.elm-exporter.source-user | Nombre de usuario asociado al token del GitHub Enterprise Server operador. Debe ser su nombre de usuario en GitHub Enterprise Server; si otra persona va a crear este token, el valor aquí debe establecerse en su nombre de usuario. Recomendamos al ghe-admin usuario. |

1. Aplique la configuración.

   Shell

   ghe-config-apply
   

2. Deje la sesión SSH. Ejecutará el resto de los comandos en una sesión de terminal local.

2. Creación de tokens de operador con acceso empresarial

El operador debe autenticarse tanto en la empresa de origen como en la de destino con un personal access token (classic). Para obtener instrucciones sobre cómo crear tokens, consulte Administración de tokens de acceso personal.

Asegúrese de anotar ambos tokens, ya que los necesitará en el paso siguiente.

1. En GitHub Enterprise Server, cree un personal access token (classic) y seleccione el ámbito requerido:

   • admin:enterprise

   Usará este token como el token de origen al configurar el ELM CLI.

2. En GHE.com, cree personal access token (classic) y seleccione los alcances necesarios:

   • admin:enterprise
   • admin:org

   Utilizará este token como token de destino al configurar el ELM CLI.

3. Configurar la herramienta ELM de línea de comandos

Ejecutarás la migración desde un terminal local, mediante una extensión del GitHub CLI.

1. Instale el GitHub CLI en su equipo local. Debe usar la versión 2.0 o posterior.

2. Instale la extensión ELM.

   Shell

   gh extension install github/gh-elm
   

3. Inicie el Asistente para la instalación para configurar la extensión.

   Shell

   gh elm configure
   

4. Siga las instrucciones del Asistente para la instalación, proporcionando las direcciones URL de API (por ejemplo: https://api.SUBDOMAIN.ghe.com) para el origen y el destino y los tokens que creó en el paso anterior.

Cualquiera de estos valores también se puede proporcionar como marcas de la CLI en cualquier gh elm comando, lo que tendrá prioridad sobre la configuración. Por ejemplo: --target-url https://api.SUBDOMAIN.ghe.com.

Este proceso de configuración almacenará las direcciones URL en un archivo de configuración específico de la plataforma en el directorio de configuración del sistema operativo, en gh-elm/config.json. Los tokens de acceso se almacenarán de forma segura en el almacenamiento secreto del equipo.

4. Configuración de los secretos de migración en vivo

Además de los tokens de operador con acceso empresarial, debe crear un personal access token (classic) para las organizaciones de origen y de destino. Debe repetir estos pasos para cada organización desde la que va a migrar.

Creación de tokens de acceso

ELM debe autenticarse con un/a personal access token (classic) tanto para el origen como para el destino de la migración. Para obtener instrucciones sobre cómo crear tokens, consulte Administración de tokens de acceso personal.

Asegúrese de anotar estos tokens, ya que los necesitará en el paso siguiente.

1. Cree un personal access token (classic) en GitHub Enterprise Server con los siguientes alcances:

   • repo
   • admin:org
   • admin:repo_hook
   • admin:org_hook

   Este es el token de origen.

2. Cree un personal access token (classic) en GHE.com con los siguientes alcances:

   • repo
   • workflow
   • admin:org
   • admin:repo_hook
   • admin:enterprise

   Este es el token de destino.

   Importante

   Si se aplica el inicio de sesión único en la organización de destino en GHE.com, debe autorizar el GHE.com token para el inicio de sesión único.

Configure los secretos de su organización ELM

Use los gh elm config comandos para establecer los tokens de acceso de origen y de destino:

1. Establezca el token de origen.

   Shell

   gh elm config set-source-pat EXISTING-GHES-ORG
   

   Pegue el token de origen en el terminal cuando se le solicite.

2. Establezca el token de destino.

   Shell

   gh elm config set-target-pat EXISTING-GHES-ORG
   

   Pegue el token de destino en el terminal cuando se le solicite.

También puede establecer los tokens de forma interactiva, mediante gh elm config org-tokens EXISTING-GHES-ORGo en la configuración de la organización en https://GHES_HOSTNAME/organizations/EXISTING-GHES-ORG/settings/secrets/elm-exporter/.

5. Cree una migración

Cree una nueva migración especificando los detalles del repositorio de origen y de destino.

gh elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO

gh elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO

Por ejemplo:

gh elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo

Marcas opcionales:

• --start: si está listo para iniciar la migración de inmediato.
• --target-visibility: los repositorios migrados se crean con visibilidad interna de forma predeterminada, pero puede especificar private.

Guardar el identificador de migración

Debería ver una respuesta similar a la siguiente:

{
  "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9",
  "expiresAt": "2026-02-11T21:49:33.619162159Z"
}

Exporte como migrationId una variable, ya que la necesitará para los siguientes comandos. Por ejemplo:

export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'

6. Iniciar la migración

Si aún no inició la migración, iníciela ahora con el identificador de migración que acaba de guardar.

gh elm migration start --migration-id $MIGRATION_ID

gh elm migration start --migration-id $MIGRATION_ID

Esto inicia los procesos de reposición y actualización dinámica. ELM está recopilando ahora datos del repositorio de origen y escuchando los eventos de webhook que se admiten.

7. Supervisión de la migración

Cuando se haya iniciado la migración, debería ver un nuevo repositorio en GHE.com. Durante la migración, verá que el repositorio se rellena con una carga inicial de datos y recibe actualizaciones a medida que los desarrolladores siguen trabajando en el repositorio de origen.

Puede supervisar el progreso de la migración de forma interactiva mediante el watch comando :

gh elm migration watch $MIGRATION_ID

Esto consultará la API del estado de la migración y mostrará una interfaz de texto que se actualiza automáticamente y refleja el progreso actual.

Supervisión programática mediante migration status

Si desea un estado de migración adecuado para la automatización, use el status comando :

gh elm migration status --migration-id $MIGRATION_ID

gh elm migration status --migration-id $MIGRATION_ID

El indicador más importante de la respuesta es el estado del objeto combinedState . Cuando el estado alcance COMBINED_STATUS_READY_FOR_CUTOVER, debe estar listo para continuar con el paso siguiente. Sin embargo, se le avisará en displayMessage si algún recurso individual no se pudo migrar, lo que puede que tenga que investigar.

Por ejemplo:

  "combinedState":  {
    "status":  "COMBINED_STATUS_READY_FOR_CUTOVER",
    "displayMessage":  "Ready for cutover (1 resources failed)",
    "repositories":  [
      {
        "repositoryNwo":  "new-test-org/my-new-repo",
        "phase":  "REPOSITORY_PHASE_READY_FOR_CUTOVER",
        "displayStatus":  "Ready for cutover (1 failed)"
      }
    ],
    "readyForCutover":  true,
    "cutoverBlockers":  []
  },

Sugerencias:

• Si ejecuta varias migraciones, puede comprobar el estado de todas ellas con gh elm migration list. Este comando muestra las migraciones en curso de forma predeterminada, pero también puede filtrar por --status.
• Si encuentra estados de error que requieren atención, consulte Solución de problemas de migraciones en vivo de GitHub Enterprise Server a GHE.com.

8. Completar la migración

Cuando una migración esté lista para el cambio final, puede completarla. El proceso de transición archivará el repositorio de origen, lo que lo convierte en de solo lectura permanentemente a menos que un administrador del repositorio lo desarchive.

gh elm migration cutover --migration-id $MIGRATION_ID

gh elm migration cutover --migration-id $MIGRATION_ID

Continúe supervisando la migración. Cuando vea el MIGRATION_STATUS_COMPLETED estado en la parte superior de la respuesta, la migración se ha completado, aunque hay algunas tareas de seguimiento para conceder acceso a los usuarios desde GitHub Enterprise Server.

Pasos siguientes

Proporcione a los usuarios acceso al nuevo repositorio y concilie la actividad con las cuentas de usuario. Consulte Finalización de la migración en vivo desde GitHub Enterprise Server a GHE.com.