Migrieren von Repositorys von .com zu Enterprise Cloud

Tool navigation

In diesem Artikel

Migrationen zu Enterprise Cloud umfassen Migrationen zwischen Konten auf .com und bei Einführung der Datenresidenz Migrationen zur Unterdomäne deines Unternehmens auf GHE.com.

Du kannst deine Migration entweder mit der CLI oder mit der API ausführen.

Die 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 Enterprise Importer zu erstellen.

Um Anweisungen für die Verwendung der API anzuzeigen, verwendest du den Toolumschalter oben auf der Seite.
Um Anweisungen zur Verwendung der CLI anzuzeigen, verwendest du den Toolumschalter oben auf der Seite.

  • 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 -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 -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 -Produkten.

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 -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 Enterprise-Cloud mit Datenresidenz sicher, dass du Abfragen an den Endpunkt für die Unterdomäne für GHE.com sendest.

Verwende als Organisationsbesitzer*in in 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.

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
AbfragevariableBeschreibung
loginName deiner Organisation.

{
  "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.

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 .com.

mutation createMigrationSource($name: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: "https://.com", ownerId: $ownerId, type: _ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

Hinweis

Stelle sicher, dass du _ARCHIVE für type verwendest.

AbfragevariableBeschreibung
nameEin Name für deine Migrationsquelle. Dieser Name dient deiner eigenen Referenz, sodass du eine beliebige Zeichenfolge angeben kannst.
ownerIdDie Organisations-ID deiner Organisation in Enterprise Cloud.

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": ".com Source",
        "url": "https://.com",
        "type": "_SOURCE"
      }
    }
  }
}

In diesem Beispiel ist MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA die ID der Migrationsquelle, die du im nächsten Schritt verwendest.

Wenn du eine Migration startest, werden ein einzelnes Repository und die zugehörigen Daten zu einem neuen -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.

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $Pat: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    Pat: $Pat,
    targetRepoVisibility: $targetRepoVisibility
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}
AbfragevariableBeschreibung
sourceIdDie id deiner Migrationsquelle, die von der createMigrationSource-Mutation zurückgegeben wurde.
ownerIdDie Organisations-ID deiner Organisation in Enterprise Cloud.
repositoryNameEin benutzerdefinierter eindeutiger Repositoryname, der derzeit von keinem deiner Repositorys im Besitz der Organisation auf Enterprise Cloud verwendet wird. Wenn die Migration abgeschlossen oder beendet wurde, wird ein Fehlerprotokollierungsproblem in diesem Repository erstellt.
continueOnErrorMigrationseinstellung, 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.
PatDas personal access token für deine Zielorganisation auf Enterprise Cloud.
accessTokenDas personal access token für deine Quelle.
targetRepoVisibilityDie Sichtbarkeit des neuen Repositorys. Muss private, public oder internal sein. Wenn sie nicht festgelegt wurde, wird dein Repository als privat migriert.
sourceRepositoryUrlDie URL deines Quellrepositorys im Format https://.com/{organization}/{repository}.

Weitere Informationen zu den Anforderungen für personal access token findest du unter Verwalten des Zugriffs für eine Migration zwischen -Produkten.

Im nächsten Schritt verwendest du die von der startRepositoryMigration-Mutation zurückgegebene Migrations-ID, um den Migrationsstatus zu überprüfen.

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.

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
AbfragevariableBeschreibung
idDie id deiner Migration, die von der startRepositoryMigration-Mutation zurückgegeben wurde.

Um die Migration abzuschließen, solltest du das Issue „Migrationsprotokoll“ überprüfen. Dieses Problem wird in im Zielrepository erstellt.

Screenshot eines Problems mit dem Titel „Migrationsprotokoll“. Der zweite Kommentar im Issue enthält Protokolle für eine Migration.

Abschließend wird empfohlen, die Integrität deiner migrierten Repositorys zu überprüfen.

Wenn dies deine erste Migration ist, musst du die GEI extension of the CLI installieren. Weitere Informationen zur CLI findest du unter Informationen zur CLI.

Alternativ können Sie eine eigenständige Binärdatei von der Veröffentlichungsseite für das /gh-gei-Repository herunterladen. Sie können daraufhin die Binärdatei direkt ohne das gh-Präfix ausführen.

  1. Installiere die CLI. Installationsanweisungen für CLI findest du im CLI-Repository.

    Hinweis

    Du benötigst Version 2.4.0 oder höher der CLI. Die installierte Version kannst du mit dem Befehl gh --version ermitteln.

  2. Installiere die GEI extension.

    Shell
    gh extension install /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.

Die GEI extension wird wöchentlich aktualisiert. Aktualisieren die Erweiterung, um sicherzustellen, dass du die neueste Version verwendest.

gh extension upgrade /gh-gei

Bevor du GEI extension zum Migrieren zu 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.

  1. Erstelle ein personal access token (classic) für die Authentifizierung der Zielorganisation auf Enterprise Cloud, und stelle sicher, dass das Token alle Anforderungen erfüllt. Weitere Informationen finden Sie unter Verwalten des Zugriffs für eine Migration zwischen -Produkten.

  2. Erstelle ein personal access token für die Authentifizierung der Quellorganisation, und stelle außerdem sicher, dass dieses Token alle Anforderungen erfüllt.

  3. 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 das GH_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"

  4. Lege bei der Migration zu Enterprise-Cloud mit Datenresidenz der Einfachheit halber eine Umgebungsvariable für die Basis-API-URL für dein Unternehmen fest.

    • Wenn du ein Terminal verwendest, führe den Befehl export aus.

      Shell
      export TARGET_API_URL="https://api.octocorp.ghe.com"

    • Wenn du PowerShell verwendest, führe den Befehl $env aus.

      Shell
      $env:TARGET_API_URL="https://api.octocorp.ghe.com"

    Du verwendest diese Variable mit der Option --target-api-url in Befehlen, die du mit der CLI ausführst.

Wenn du mehrere Repositorys gleichzeitig zu Enterprise Cloud migrieren möchtest, verwendest du die CLI, um ein Migrationsskript zu generieren. Das resultierende Skript enthält eine Liste von Migrationsbefehlen (einen pro Repository).

Hinweis

Beim Generieren eines Skripts wird ein PowerShell-Skript ausgegeben. Wenn du ein Terminal verwendest, musst du das Skript mit der Erweiterung .ps1 ausgeben und PowerShell für Mac oder Linux installieren, um es auszuführen.

Wenn du ein einzelnes Repository migrieren möchtest, fahre mit dem nächsten Schritt fort.

Führe den Befehl gh gei generate-script aus, um ein Migrationsskript zu generieren.

Shell
gh gei generate-script ---source-org SOURCE ---target-org DESTINATION --output FILENAME

Wenn Sie GEI als eigenständige Binärdatei heruntergeladen haben und nicht als Erweiterung für die CLI, müssen Sie das generierte Skript aktualisieren, um die Binärdatei anstelle von gh gei auszuführen.

Ersetze die Platzhalter im obigen Befehl durch die folgenden Werte.

PlatzhalterWert
SOURCEName der Ursprungsorganisation
DESTINATIONName der Zielorganisation
FILENAMEEin 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.

ArgumentBeschreibung
--target-api-url TARGET-API-URLWenn du zu GHE.com migrierst, füge --target-api-url TARGET-API-URL hinzu, wobei TARGET-API-URL die Basis-API-URL für die Unterdomäne deines Unternehmens ist. Beispiel: https://api.octocorp.ghe.com
--download-migration-logsÜberprüfe das Migrationsprotokoll für jedes migrierte Repository. Weitere Informationen zu Migrationsprotokollen findest du unter Zugreifen auf die Migrationsprotokolle für Enterprise Importer.

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.
  • Wenn Sie die Sichtbarkeit des neuen Repositorys ändern möchten, aktualisieren Sie den Wert für das entsprechende Flag --target-repo-visibility. Standardmäßig legt das Skript die gleiche Sichtbarkeit wie für das Quellrepository fest.

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.

Wenn Sie GEI als eigenständige Binärdatei heruntergeladen haben und nicht als Erweiterung für die CLI, müssen Sie das generierte Skript aktualisieren, um die Binärdatei anstelle von gh gei auszuführen.

Mit dem Befehl gh gei migrate-repo kannst mehrere Repositorys mit einem Migrationsskript oder einem einzelnen Repository migrieren.

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

Verwende den Befehl gh gei migrate-repo, um ein einzelnes Repository zu migrieren.

Shell
gh gei migrate-repo ---source-org SOURCE --source-repo CURRENT-NAME ---target-org DESTINATION --target-repo NEW-NAME

Ersetze die Platzhalter im obigen Befehl durch die folgenden Werte.

PlatzhalterWert
SOURCEName der Ursprungsorganisation
CURRENT-NAMEDer Name des Repositorys, das du migrieren möchtest
DESTINATIONName der Zielorganisation
NEW-NAMEDer Name für das migrierte Repository

ArgumentBeschreibung
--target-api-url TARGET-API-URLWenn du zu GHE.com migrierst, füge --target-api-url TARGET-API-URL hinzu, wobei TARGET-API-URL die Basis-API-URL für die Unterdomäne deines Unternehmens ist. Beispiel: https://api.octocorp.ghe.com
--skip-releasesWenn 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.
--target-repo-visibility TARGET-VISIBILITYRepositorys werden standardmäßig mit privater Sichtbarkeit migriert. Um die Sichtbarkeit festzulegen, können Sie das Flag --target-repo-visibility hinzufügen und private, public oder internal angeben. Wenn Sie zu Unternehmen mit verwalteten Benutzer*innen migrieren, sind öffentliche Repositorys nicht verfügbar.

Wenn Sie eine Migration abbrechen möchten, verwenden Sie den Befehl abort-migration und ersetzen Sie die MIGRATIONS-ID durch die zurückgesendete ID migrate-repo.

Shell
gh gei abort-migration --migration-id MIGRATION-ID

Nachdem die Migration abgeschlossen ist, solltest du das Migrationsprotokoll überprüfen. Weitere Informationen finden Sie unter Zugreifen auf die Migrationsprotokolle für Enterprise Importer.

Es wird empfohlen, die Integrität deiner migrierten Repositorys zu überprüfen.