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. Consulta 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 obtener 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
}
}
}
Note
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 create. |
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. |
target | La visibilidad del nuevo repositorio. Debe ser private, public o internal. Si no se establece, el repositorio se migra como privado. |
source | URL del repositorio de origen, con el formato https:/. |
Para obtener los requisitos de personal access token, consulta 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 start. |
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.