Informationen zu Repositorymigrationsvorgängen mit GitHub Enterprise Importer
Migrationen zu GitHub Enterprise Cloud umfassen Migrationen zwischen Konten auf GitHub.com und bei Einführung der Datenresidenz Migrationen zur Unterdomäne deines Unternehmens auf GHE.com.
Du kannst deine Migration entweder mit der GitHub CLI oder mit der API ausführen.
Die GitHub CLI vereinfacht den Migrationsprozess und wird für die meisten Kundinnen empfohlen. Fortgeschrittene Kundinnen, die viele Anpassungen vornehmen müssen, können die API verwenden, um eigene Integrationen mit dem GitHub Enterprise Importer zu erstellen.
Note
Wenn das Repository, das Sie migrieren, Regeln enthält, die dem eingehenden Repository nicht entsprechen, wird die Migration blockiert. Um diese Regelets zu umgehen und die Migration zuzulassen, können Sie eine Regelsatzumgehung für alle Bereitstellungsschlüssel in der Zielorganisation anwenden.
Repositoryregeln können auf Organisationsebene festgelegt werden. Wenn das eingehende Repository keinem dieser Regelsätze entspricht, müssen Sie die Umgehung des Bereitstellungsschlüssels für jeden dieser Sätze verwenden. Weitere Informationen findest du unter Erstellen von Regelsätzen für Repositorys in deiner Organisation.
Voraussetzungen
- Es wird dringend empfohlen, einen Testlauf deiner Migration durchzuführen und die Produktionsmigration bald danach abzuschließen. Weitere Informationen zu Testläufen findest du unter Übersicht über die Migration zwischen GitHub-Produkten.
- Stellen Sie sicher, dass Sie die zu migrierenden Daten und die bekannten Supportbeschränkungen des Importer verstehen. Weitere Informationen findest du unter Informationen zu Migrationen zwischen GitHub-Produkten.
- Es ist zwar nicht erforderlich, die Arbeit während der Produktionsmigration zu unterbrechen, es wird aber empfohlen. Der Importer unterstützt keine Deltamigrationen, sodass Änderungen, die während der Migration vorgenommen werden, nicht migriert werden. Wenn du dich dafür entscheidest, die Arbeit während der Produktionsmigration nicht zu unterbrechen, musst du diese Änderungen manuell migrieren.
- Sowohl in der Quell- als auch in der Zielorganisation musst du entweder Organisationsbesitzer*in sein, oder dir muss die Migrationsrolle zugewiesen sein. Weitere Informationen finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.
Schritt 0: Vorbereiten der Verwendung der GraphQL-API von GitHub
Um GraphQL-Abfragen zu erstellen, musst du eigene Skripts schreiben oder einen HTTP-Client wie Insomnia verwenden.
Weitere Informationen zu den ersten Schritten mit der GitHub-GraphQL-API, einschließlich der Authentifizierung, findest du unter Erstellen von Aufrufen mit GraphQL.
Du sendest alle GraphQL-Abfragen an das Ziel deiner Migration. Stelle bei der Migration zu GitHub Enterprise-Cloud mit Datenresidenz sicher, dass du Abfragen an den Endpunkt für die Unterdomäne für GHE.com sendest.
Schritt 1: Abrufen der ownerId für dein Migrationsziel
Verwende als Organisationsbesitzer*in in GitHub Enterprise Cloud die Abfrage GetOrgInfo, um die ownerId (auch als Organisations-ID bezeichnet) für die Organisation zurückzugeben, der du den Besitz der migrierten Repositorys zuordnen möchtest. Du benötigst die ownerId, um das Migrationsziel anzugeben.
Abfrage GetOrgInfo
query(
$login: String!
){
organization (login: $login)
{
login
id
name
databaseId
}
}
| Abfragevariable | Beschreibung |
|---|---|
login | Name deiner Organisation. |
Antwort von GetOrgInfo
{
"data": {
"organization": {
"login": "Octo",
"id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
"name": "Octo-org",
"databaseId": 5610
}
}
}
In diesem Beispiel ist MDEyOk9yZ2FuaXphdGlvbjU2MTA= die Organisations-ID oder die ownerId, die du im nächsten Schritt verwendest.
Schritt 2: Ermitteln der Migrationsquelle
Du kannst eine Migrationsquelle mithilfe der Abfrage createMigrationSource einrichten. Du musst die ownerId oder die Organisations-ID angeben, die du mit der Abfrage GetOrgInfo abgerufen hast.
Deine Migrationsquelle ist eine Organisation auf GitHub.com.
createMigrationSource-Mutation
mutation createMigrationSource($name: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: "https://github.com", ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
migrationSource {
id
name
url
type
}
}
}
Note
Stelle sicher, dass du GITHUB_ARCHIVE für type verwendest.
| Abfragevariable | Beschreibung |
|---|---|
name | Ein Name für deine Migrationsquelle. Dieser Name dient deiner eigenen Referenz, sodass du eine beliebige Zeichenfolge angeben kannst. |
ownerId | Die Organisations-ID deiner Organisation in GitHub Enterprise Cloud. |
Antwort von createMigrationSource
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
"name": "GitHub.com Source",
"url": "https://github.com",
"type": "GITHUB_SOURCE"
}
}
}
}
In diesem Beispiel ist MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA die ID der Migrationsquelle, die du im nächsten Schritt verwendest.
Schritt 3: Starten der Repositorymigration
Wenn du eine Migration startest, werden ein einzelnes Repository und die zugehörigen Daten zu einem neuen GitHub-Repository migriert, das du angibst.
Wenn du mehrere Repositorys gleichzeitig aus derselben Quellorganisation verschieben möchtest, kannst du mehrere Migrationsvorgänge in die Warteschlange einreihen. Du kannst bis zu fünf Migrationsvorgänge gleichzeitig ausführen.
startRepositoryMigration-Mutation
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
}
}
}
| Abfragevariable | Beschreibung |
|---|---|
sourceId | Die id deiner Migrationsquelle, die von der create-Mutation zurückgegeben wurde. |
ownerId | Die Organisations-ID deiner Organisation in GitHub Enterprise Cloud. |
repositoryName | Ein benutzerdefinierter eindeutiger Repositoryname, der derzeit von keinem deiner Repositorys im Besitz der Organisation auf GitHub Enterprise Cloud verwendet wird. Wenn die Migration abgeschlossen oder beendet wurde, wird ein Fehlerprotokollierungsproblem in diesem Repository erstellt. |
continueOnError | Migrationseinstellung, mit der die Migration fortgesetzt werden kann, wenn Fehler auftreten, die nicht dazu führen, dass die Migration fehlerhaft wird. Muss true oder false sein. Es wird dringend empfohlen continueOnError auf true festzulegen, damit die Migration fortgesetzt wird, es sei denn, der Importer kann die Git-Quelle nicht verschieben oder der Importer hat die Verbindung unterbrochen und kann die Verbindung nicht wiederherstellen, um die Migration abzuschließen. |
githubPat | Das personal access token für deine Zielorganisation auf GitHub Enterprise Cloud. |
accessToken | Das personal access token für deine Quelle. |
target | Die Sichtbarkeit des neuen Repositorys. Muss private, public oder internal sein. Wenn sie nicht festgelegt wurde, wird dein Repository als privat migriert. |
source | Die URL deines Quellrepositorys im Format https:/. |
Weitere Informationen zu den Anforderungen für personal access token findest du unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.
Im nächsten Schritt verwendest du die von der startRepositoryMigration-Mutation zurückgegebene Migrations-ID, um den Migrationsstatus zu überprüfen.
Schritt 4: Überprüfen des Migrationsstatus
Um Migrationsfehler zu erkennen und sicherzustellen, dass deine Migration funktioniert, kannst du den Migrationsstatus mithilfe der Abfrage getMigration überprüfen. Du kannst auch den Status mehrerer Migrationsvorgänge mit getMigrations überprüfen.
Die Abfrage getMigration gibt für die Migration einen der folgenden Status zurück: queued, in progress, failed oder completed. Wenn die Migration fehlerhaft war, gibt der Importer einen Grund für den Fehler an.
Abfrage getMigration
query (
$id: ID!
){
node( id: $id ) {
... on Migration {
id
sourceUrl
migrationSource {
name
}
state
failureReason
}
}
}
| Abfragevariable | Beschreibung |
|---|---|
id | Die id deiner Migration, die von der start-Mutation zurückgegeben wurde. |
Schritt 5: Überprüfen der Migration und des Fehlerprotokolls
Um die Migration abzuschließen, solltest du das Issue „Migrationsprotokoll“ überprüfen. Dieses Problem wird in GitHub im Zielrepository erstellt.
Abschließend wird empfohlen, die Integrität deiner migrierten Repositorys zu überprüfen.