Hinweis: Der GitHub Enterprise Importer liegt derzeit als öffentliche Betaversion vor und kann noch geändert werden.
Informationen zu Repositorymigrationsvorgängen mit GitHub Enterprise Importer
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.
Voraussetzungen
- To ensure you understand the known support limitations of the Importer, review "About GitHub Enterprise Importer."
- We strongly recommend that you perform a trial run of your migration and complete your production migration soon after. To learn more about trial run best practices, see "Vorbereiten einer Migration mit GitHub Enterprise Importer."
- 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.
- Du musst entweder Organisationsbesitzer*in sein, oder dir muss die Migrationsrolle für die Quell- und Zielorganisation zugewiesen sein. Weitere Informationen findest du unter Zuweisen der Migrationsrolle zu GitHub Enterprise Importer.
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.
Schritt 1: Abrufen der ownerId
für dein Migrationsziel
As an organization owner in GitHub Enterprise Cloud, use the GetOrgInfo
query to return the ownerId
, also called the organization ID, for the organization you want to own the migrated repositories. You'll need the ownerId
to identify your migration destination.
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
}
}
}
Hinweis: 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
When you start a migration, a single repository and its accompanying data migrates into a brand new GitHub repository that you identify.
If you want to move multiple repositories at once from the same source organization, you can queue multiple migrations. You can run up to 5 repository migrations at the same time.
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
}
}
}
Query variable | Description |
---|---|
sourceId | Your migration source id returned from the createMigrationSource mutation. |
ownerId | The organization ID of your organization on GitHub Enterprise Cloud. |
repositoryName | A custom unique repository name not currently used by any of your repositories owned by the organization on GitHub Enterprise Cloud. An error-logging issue will be created in this repository when your migration is complete or has stopped. |
continueOnError | Migration setting that allows the migration to continue when encountering errors that don't cause the migration to fail. Must be true or false . We highly recommend setting continueOnError to true so that your migration will continue unless the Importer can't move Git source or the Importer has lost connection and cannot reconnect to complete the migration. |
githubPat | The personal access token for your destination organization on GitHub Enterprise Cloud. For personal access token requirements, see "Verwalten des Zugriffs für GitHub Enterprise Importer." |
accessToken | The personal access token for your source. |
targetRepoVisibility | The visibility of the new repository. Must be private , public , or internal . If not set, your repository is migrated as private. |
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
To detect any migration failures and ensure your migration is working, you can check your migration status using the getMigration
query. You can also check the status of multiple migrations with getMigrations
.
The getMigration
query will return with a status to let you know if the migration is queued
, in progress
, failed
, or completed
. If your migration failed, the Importer will provide a reason for the failure.
getMigration
query
query (
$id: ID!
){
node( id: $id ) {
... on Migration {
id
sourceUrl
migrationSource {
name
}
state
failureReason
}
}
}
Query variable | Description |
---|---|
id | The id of your migration that the startRepositoryMigration mutation returned. |
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.
Schritt 1: Installieren der GEI extension of the GitHub CLI
Wenn dies deine erste Migration ist, musst du die GEI extension of the GitHub CLI installieren. Weitere Informationen zur GitHub CLI findest du unter Informationen zur GitHub CLI.
-
Installiere die GitHub CLI. Installationsanweisungen für GitHub CLI findest du im GitHub CLI-Repository.
Hinweis: Du benötigst Version 2.4.0 oder höher der GitHub CLI. Die installierte Version kannst du mit dem Befehl
gh --version
ermitteln.Shell gh extension install github/gh-gei
Wenn du Hilfe zur GEI extension benötigst, kannst du immer das Flag --help
mit einem Befehl verwenden. Mit gh gei --help
listest du z. B. alle verfügbaren Befehle auf, und mit gh gei migrate-repo --help
zeigst du alle Optionen an, die für den Befehl migrate-repo
verfügbar sind.
Schritt 2: Aktualisieren der GEI extension of the GitHub CLI
Die GEI extension wird wöchentlich aktualisiert. To make sure you're using the latest version, update the extension.
gh extension upgrade github/gh-gei
Schritt 3: Festlegen der Umgebungsvariablen
Bevor du GEI extension zum Migrieren zu GitHub Enterprise Cloud verwenden kannst, musst du personal access token erstellen, die auf die Quell- und Zielorganisationen zugreifen können, und dann die personal access token als Umgebungsvariablen festlegen.
-
Erstelle ein personal access token für die Authentifizierung der Zielorganisation auf GitHub Enterprise Cloud, und stelle sicher, dass das Token alle Anforderungen erfüllt. Weitere Informationen findest du unter Verwalten des Zugriffs für GitHub Enterprise Importer.
-
Erstelle ein personal access token für die Authentifizierung der Quellorganisation, und stelle außerdem sicher, dass dieses Token alle Anforderungen erfüllt. 1. Lege Umgebungsvariablen für die personal access token fest, und ersetze in den folgenden Befehlen TOKEN durch die personal access token, die du oben gespeichert hast. Verwende das
GH_PAT
für die Zielorganisation und dasGH_SOURCE_PAT
für die Quellorganisation.-
Wenn du ein Terminal verwendest, führe den Befehl
export
aus.Shell export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
-
Wenn du PowerShell verwendest, führe den Befehl
$env
aus.Shell $env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
-
Schritt 4: Generieren eines Migrationsskripts
If you want to migrate multiple repositories to GitHub Enterprise Cloud at once, use the GitHub CLI to generate a migration script. The resulting script will contain a list of migration commands, one per repository.
Note: Generating a script outputs a PowerShell script. If you're using Terminal, you will need to output the script with the .ps1
file extension and install PowerShell for either Mac or Linux to run it.
Generieren eines Migrationsskripts
Führe den Befehl gh gei generate-script
aus, um ein Migrationsskript zu generieren.
gh gei generate-script --github-source-org SOURCE --github-target-org DESTINATION --output FILENAME
If you want the script to download the migration log for each migrated repository, add the --download-migration-logs
flag. For more information about migration logs, see "Zugreifen auf die Migrationsprotokolle für GitHub Enterprise Importer."
Ersetze die Platzhalter im obigen Befehl durch die folgenden Werte.
Platzhalter | Wert |
----------- | ----- | SOURCE | Name der Ursprungsorganisation DESTINATION | Name of the destination organization FILENAME | Ein Dateiname für das resultierende Migrationsskript
Wenn du das Terminal verwendest, legst du als Erweiterung .ps1
fest, da für das generierte Skript PowerShell ausgeführt werden muss. Du kannst PowerShell für Mac oder Linux installieren.
Überprüfen des Migrationsskripts
Nachdem du das Skript generiert hast, überprüfst du die Datei, und bearbeitest ggf. das Skript.
- Wenn du einige Repositorys nicht migrieren möchtest, kannst du die entsprechenden Zeilen löschen oder auskommentieren.
- Wenn Repositorys in der Zielorganisation einen anderen Namen erhalten sollen, aktualisiere den Wert für das entsprechende Flag
--target-repo
.
Hinweis: Wenn dein Repository mehr als 10 GB Releasedaten enthält, können Releases nicht migriert werden. Verwende das Flag --skip-releases
, um das Repository ohne Releases zu migrieren.
Schritt 5: Migrieren von Repositorys
Mit dem Befehl gh gei migrate-repo
kannst mehrere Repositorys mit einem Migrationsskript oder einem einzelnen Repository migrieren.
Migrieren mehrerer Repositorys
Führe das oben generierte Skript aus, um mehrere Repositorys zu migrieren. Ersetze FILENAME in den folgenden Befehlen durch den Dateinamen, den du beim Generieren des Skripts angegeben hast.
- Wenn du ein Terminal verwendest, gibst du
./
ein.Shell ./FILENAME
- Wenn du PowerShell verwendest, gibst du
.\
ein.Shell .\FILENAME
Migrieren eines einzelnen Repositorys
Verwende den Befehl gh gei migrate-repo
, um ein einzelnes Repository zu migrieren.
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME
Hinweis: Wenn dein Repository mehr als 10 GB Releasedaten enthält, können Releases nicht migriert werden. Verwende das Flag --skip-releases
, um das Repository ohne Releases zu migrieren.
Ersetze die Platzhalter im obigen Befehl durch die folgenden Werte.
Platzhalter | Wert | ----------- | ----- | SOURCE | Name der Ursprungsorganisation CURRENT-NAME | Der Name des Repositorys, das du migrieren möchtest DESTINATION | Name of the destination organization NEW-NAME | Der Name für das migrierte Repository
Schritt 6: Überprüfen der Migration und des Fehlerprotokolls
Nachdem die Migration abgeschlossen ist, solltest du das Migrationsprotokoll überprüfen. Weitere Informationen findest du unter Zugreifen auf die Migrationsprotokolle für GitHub Enterprise Importer.
Es wird empfohlen, die Integrität deiner migrierten Repositorys zu überprüfen.