Acerca de las migraciones de repositorios con GitHub Enterprise Importer
Puedes ejecutar la migración con la GitHub CLI o la API.
La GitHub CLI simplifica el proceso de migración y se recomienda para la mayoría de los clientes. Los clientes avanzados con necesidades de personalización intensivas pueden usar la API para crear sus propias integraciones con GitHub Enterprise Importer.
Note
Si el repositorio que va a migrar tiene conjuntos de reglas que no coinciden en el repositorio entrante, se bloqueará la migración. Para omitir estos conjuntos de reglas y permitir la migración, puede aplicar una omisión de conjunto de reglas para todas las claves de implementación de la organización de destino.
Los conjuntos de reglas de repositorio se pueden establecer en el nivel de organización. Si no coincide ningún conjunto de reglas en el repositorio entrante, deberá usar la omisión de claves de implementación para cada uno de ellos. Consulte "Creación de conjuntos de reglas para repositorios de la organización".
Requisitos previos
- Se recomienda encarecidamente realizar una ejecución de prueba de la migración y completar la migración de producción poco después. Para más información sobre las ejecuciones de prueba, consulta "Introducción a una migración desde Azure DevOps a GitHub Enterprise Cloud".
- Asegúrate de comprender los datos que se migrarán y las limitaciones de compatibilidad conocidas del importador. Para más información, consulta "Información sobre migraciones desde Azure DevOps a GitHub Enterprise Cloud".
- Aunque no es necesario, se recomienda detener el trabajo durante la migración de producción. Importer no admite migraciones diferenciales, por lo que los cambios que se produzcan durante la migración no se migrarán. Si decides no detener el trabajo durante la migración de producción, tendrás que migrar manualmente estos cambios.
- Para la organización de destino en GitHub, debe ser propietario de la organización o tener el rol de migración. Para más información sobre el rol de migración, consulta "Administración del acceso para una migración desde Azure DevOps".
Paso 0: Preparación para usar GraphQL API de GitHub
Para realizar consultas de GraphQL, tendrás que escribir scripts propios, o bien usar un cliente HTTP como Insomnia.
Para más información sobre cómo empezar a trabajar con GraphQL API de GitHub, incluido cómo autenticarse, consulta "Formar llamados con GraphQl".
Enviarás todas las consultas de GraphQL al destino de tu migración. Si vas a migrar a Nube de GitHub Enterprise con residencia de datos, asegúrate de enviar consultas al punto de conexión del subdominio de la empresa de GHE.com.
Paso 1: Obtención de ownerId para el destino de la migración
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
}
}
| Variable de consulta | Descripción |
|---|---|
login | El nombre de la organización. |
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 2: Identificación del origen de la migración
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 la migración es la organización de ADO.
Mutación createMigrationSource
mutation createMigrationSource($name: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
migrationSource {
id
name
url
type
}
}
}
Nota: Asegúrate de usar AZURE_DEVOPS para type.
| Variable de consulta | Descripción |
|---|---|
name | Nombre para el origen de la migración. Este nombre es para referencia propia, por lo que puedes usar cualquier cadena. |
ownerId | El id. de la organización en GitHub Enterprise Cloud. |
Respuesta createMigrationSource
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
"name": "Azure Devops Source",
"url": "https://dev.azure.com",
"type": "AZURE_DEVOPS"
}
}
}
}
En este ejemplo, MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA es el id. de origen de la migración, que se usará en el paso siguiente.
Paso 3: 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!,
$sourceRepositoryUrl: URI!,
$repositoryName: String!,
$continueOnError: Boolean!,
$accessToken: String!,
$githubPat: String!,
$targetRepoVisibility: String!
){
startRepositoryMigration( input: {
sourceId: $sourceId,
ownerId: $ownerId,
repositoryName: $repositoryName,
continueOnError: $continueOnError,
accessToken: $accessToken,
githubPat: $githubPat,
targetRepoVisibility: $targetRepoVisibility
sourceRepositoryUrl: $sourceRepositoryUrl,
}) {
repositoryMigration {
id
migrationSource {
id
name
type
}
sourceUrl
}
}
}
| Variable de consulta | Descripción |
|---|---|
sourceId | El origen de migración id devuelto por la mutación createMigrationSource. |
ownerId | El id. de la organización en GitHub Enterprise Cloud. |
repositoryName | Un nombre de repositorio único personalizado que actualmente no se use en ninguno de los repositorios propiedad de la organización en GitHub Enterprise Cloud. Se creará una incidencia de registro de errores en este repositorio cuando se complete la migración o se haya detenido. |
continueOnError | Valor de migración que permite que continúe al encontrar errores que no hacen que se produzca un error en la migración. Debe ser true o false. Se recomienda encarecidamente establecer continueOnError en true para que la migración continúe a menos que Importer no pueda mover el origen de Git o Importer haya perdido la conexión y no se pueda volver a conectar para completar la migración. |
githubPat | El valor personal access token de la organización de destino en GitHub Enterprise Cloud. |
accessToken | El valor personal access token para el origen. |
targetRepoVisibility | La visibilidad del nuevo repositorio. Debe ser private, public o internal. Si no se establece, el repositorio se migra como privado. |
sourceRepositoryUrl | URL del repositorio de origen, con el formato https://dev.azure.com/{organization}/{project}/_git/{repository}. |
Para obtener los requisitos de personal access token, consulte "Administración del acceso para una migración desde Azure DevOps".
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 4: 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
}
}
}
| Variable de consulta | Descripción |
|---|---|
id | El valor id de la migración que ha devuelto la mutación startRepositoryMigration. |
Paso 5: 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.
Paso 1: Instalación de ADO2GH extension of the GitHub CLI
Si se trata de la primera migración, tendrás que instalar ADO2GH extension of the GitHub CLI. Para más información sobre GitHub CLI, consulte "Acerca del CLI de GitHub".
Como alternativa, puede descargar un binario independiente desde la página de versiones del repositorio github/gh-ado2gh. Puede ejecutar el archivo binario directamente, sin el prefijo gh.
-
Instala la GitHub CLI. A fin de obtener instrucciones de instalación para GitHub CLI, vea el repositorio de GitHub CLI.
Nota: Necesitas la versión 2.4.0 o posterior de la GitHub CLI. Puedes comprobar la versión instalada con el comando
gh --version. -
Instalación de ADO2GH extension.
Shell gh extension install github/gh-ado2gh
gh extension install github/gh-ado2gh
Cada vez que necesites ayuda con ADO2GH extension, puedes usar la marca --help con un comando. Por ejemplo, gh ado2gh --help enumerará todos los comandos disponibles y gh ado2gh migrate-repo --help todas las opciones disponibles para el comando migrate-repo.
Paso 2: Actualización de ADO2GH extension of the GitHub CLI
ADO2GH extension of the GitHub CLI se actualiza semanalmente. Para asegurarte de que usas la versión más reciente, actualiza la extensión.
gh extension upgrade github/gh-ado2gh
gh extension upgrade github/gh-ado2gh
Paso 3: Establecimiento de variables de entorno
Para poder usar la ADO2GH extension para la migración a GitHub Enterprise Cloud, debes crear instancias de personal access token que puedan acceder a las organizaciones de origen y destino y, después, establecer las instancias de personal access token como variables de entorno.
-
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 desde Azure DevOps».
-
Crea y registra una instancia de personal access token que se autenticará para la organización de origen en Azure DevOps, y asegúrate de que este token cumple todos los requisitos. Para obtener más información, vea «Administración del acceso para una migración desde Azure DevOps».
-
Establece variables de entorno para personal access token, y reemplaza TOKEN en los comandos siguientes por los valores personal access token que has registrado antes. Usa
GH_PATpara la organización de destino yADO_PATpara la de origen.-
Si usas Terminal, utiliza el comando
export.Shell export GH_PAT="TOKEN" export ADO_PAT="TOKEN"
export GH_PAT="TOKEN" export ADO_PAT="TOKEN" -
Si usas PowerShell, utiliza el comando
$env.Shell $env:GH_PAT="TOKEN" $env:ADO_PAT="TOKEN"
$env:GH_PAT="TOKEN" $env:ADO_PAT="TOKEN"
-
-
Si vas a migrar a Nube de GitHub Enterprise con residencia de datos, para mayor comodidad, establece una variable de entorno para la dirección URL de la API base para tu empresa. Por ejemplo:
Shell export TARGET_API_URL="https://api.octocorp.ghe.com"
export TARGET_API_URL="https://api.octocorp.ghe.com"Usarás esta variable con la opción
--target-api-urlen los comandos que ejecutes con la GitHub CLI.
Paso 4: Generación de un script de migración
Si quieres migrar varios repositorios a GitHub Enterprise Cloud a la vez, usa la GitHub CLI para generar un script de migración. El script resultante contendrá una lista de comandos de migración, uno por cada repositorio.
Nota: La generación de un script genera un script de PowerShell. Si usas Terminal, tendrás que generar el script con la extensión de archivo .ps1 e instalar PowerShell para Mac o Linux para ejecutarlo.
Si quieres migrar un único repositorio, pasa al paso siguiente.
Generación de un script de migración
Para generar un script de migración, ejecuta el comando gh ado2gh generate-script.
gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output FILENAME
gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output FILENAME
Marcadores de posición
Reemplaza los marcadores de posición del comando anterior por los valores siguientes.
| Marcador de posición | Value |
|---|---|
| SOURCE | Nombre de la organización de origen |
| DESTINATION | Nombre de la organización de destino |
| FILENAME | Nombre de archivo para el script de migración resultante Si usas Terminal, utiliza una extensión de archivo .ps1, ya que el script generado necesita que se ejecute PowerShell. Puedes instalar PowerShell para Mac o Linux. |
Argumentos adicionales
| Argumento | Descripción |
|---|---|
--target-api-url TARGET-API-URL | Si vas a migrar a GHE.com, agrega --target-api-url TARGET-API-URL, donde TARGET-API-URL es la dirección URL de la API base para el subdominio de la empresa. Por ejemplo: https://api.octocorp.ghe.com. |
--all | Agregue funcionalidad adicional al script, como las canalizaciones de reintento, la creación de equipos y la configuración de integraciones Azure Boards. |
--download-migration-logs | Descarga el registro de migración para cada repositorio migrado. Para más información sobre los registros de migración, consulta "Acceso a los registros de migración para GitHub Enterprise Importer". |
Revisión del script de migración
Después de generar el script, revisa el archivo y, opcionalmente, edita el script.
- Si hay repositorios que no quieras migrar, elimina o convierte en comentario las líneas correspondientes.
- Si quieres que los repositorios tengan otro nombre en la organización de destino, actualiza el valor de la marca
--target-repocorrespondiente. - Si desea cambiar la visibilidad del nuevo repositorio, actualice el valor de la marca
--target-repo-visibilitycorrespondiente. De manera predeterminada, el script establece la misma visibilidad que el repositorio de origen.
Si descargó ADO2GH como un binario independiente en lugar de como una extensión para los GitHub CLI, deberá actualizar el script generado para ejecutar el binario en lugar de gh ado2gh.
Paso 5: Migración de repositorios
Puedes migrar varios repositorios con un script de migración, o bien un único repositorio con el comando gh ado2gh migrate-repo.
Migración de varios repositorios
Para migrar varios repositorios, ejecuta el script que has generado antes. Reemplaza FILENAME en los comandos siguientes por el nombre de archivo que has proporcionado al generar el script.
-
Si usas Terminal, utiliza
./.Shell ./FILENAME
./FILENAME -
Si usas PowerShell, utiliza
.\.Shell .\FILENAME
.\FILENAME
Migración de un único repositorio
Para migrar un único repositorio, usa el comando gh ado2gh migrate-repo.
gh ado2gh migrate-repo --ado-org SOURCE --ado-team-project TEAM-PROJECT --ado-repo CURRENT-NAME --github-org DESTINATION --github-repo NEW-NAME
gh ado2gh migrate-repo --ado-org SOURCE --ado-team-project TEAM-PROJECT --ado-repo CURRENT-NAME --github-org DESTINATION --github-repo NEW-NAME
Note
Si vas a migrar a GHE.com, agrega --target-api-url TARGET-API-URL, donde TARGET-API-URL es la dirección URL de la API base para el subdominio de la empresa. Por ejemplo: https://api.octocorp.ghe.com.
Reemplaza los marcadores de posición del comando anterior por los valores siguientes.
| Marcador de posición | Value |
|---|---|
| SOURCE | Nombre de la organización de origen |
| CURRENT-NAME | Nombre del repositorio que quieres migrar |
| DESTINATION | Nombre de la organización de destino |
| NEW-NAME | Nombre que quieres que tenga el repositorio migrado |
| TEAM-PROJECT | Nombre del proyecto de equipo del repositorio que quieres migrar |
Si deseas cancelar una migración, usa el comando abort-migration, reemplazando MIGRATION-ID por el identificador devuelto de migrate-repo.
gh ado2gh abort-migration --migration-id MIGRATION-ID
gh ado2gh abort-migration --migration-id MIGRATION-ID
Paso 6: Validación de la migración y comprobación del registro de errores
Una vez que se complete la migración, se recomienda revisar el registro de migración. Para obtener más información, vea «Acceso a los registros de migración para GitHub Enterprise Importer».
Se recomienda revisar los repositorios migrados para obtener una comprobación de solidez.