Vorbereiten der migrierten Daten
-
Kopiere mithilfe des
scp
-Befehls das Migrationsarchiv, das über deine Quellinstanz oder Organisation generiert wurde, in dein GitHub Enterprise Server-Ziel:scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
-
Stellen Sie eine SSH-Verbindung mit Ihrer GitHub Enterprise Server-Zielinstanz her. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
ssh -p 122 admin@HOSTNAME
-
Führe den Befehl
ghe-migrator prepare
aus, um das Archiv für den Import auf der Zielinstanz vorzubereiten, und generiere eine neue Migrations-GUID, die du in den nachfolgenden Schritten verwendest:ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
- Führe
ghe-migrator prepare
erneut aus, und rufe eine neue Migrations-GUID ab, um einen neuen Importversuch zu starten. - Um anzugeben, wo Migrationsdateien gestaget werden sollen, füge dem Befehl
--staging-path=/full/staging/path
an. Wird standardmäßig auf/data/user/tmp
festgelegt.
- Führe
Liste mit Migrationskonflikten generieren
-
Verwende den
ghe-migrator conflicts
-Befehl mit der Migrations-GUID, um eine conflicts.csv-Datei zu generieren:ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
- Wenn keine Konflikte gemeldet werden, können Sie die Daten sicher importieren.
-
Verwende bei Konflikten den
scp
-Befehl, um conflicts.csv auf deinen lokalen Computer zu kopieren:scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
-
Fahre mit Beheben von Migrationskonflikten oder Einrichten benutzerdefinierter Zuordnungen fort.
Migrationskonflikte überprüfen
- Öffne conflicts.csv mit einem Text-Editor oder einer CSV-kompatiblen Tabellensoftware.
- Überprüfe die Datei conflicts.csv, um sicherzustellen, dass beim Import die richtigen Aktionen ausgeführt werden. Berücksichtige dabei die Anleitung für die folgenden Beispiele und Verweistabellen.
Die conflicts.csv-Datei enthält eine Migrationszuordnung von Konflikten und empfohlenen Aktionen. Eine Migrationszuordnung listet auf, welche Daten von der Quellinstanz migriert werden und wie die Daten auf die Zielinstanz angewendet werden.
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/octocat | map |
organization | https://example-gh.source/octo-org | https://example-gh.target/octo-org | map |
repository | https://example-gh.source/octo-org/widgets | https://example-gh.target/octo-org/widgets | rename |
team | https://example-gh.source/orgs/octo-org/teams/admins | https://example-gh.target/orgs/octo-org/teams/admins | merge |
project | https://example-gh.source/octo-org/widgets/projects/1 | https://example-gh.target/octo-org/projects/1 | merge |
Jede Zeile in conflicts.csv bietet die folgenden Informationen:
Name | BESCHREIBUNG |
---|---|
model_name | Der Typ der zu ändernden Daten. |
source_url | Die Quell-URL der Daten. |
target_url | Die erwartete Ziel-URL der Daten. |
recommended_action | Bevorzugte Aktion, die ghe-migrator beim Importieren von Daten ausführt |
Mögliche Zuordnungen für jeden Datensatztyp
Es gibt einige verschiedene Zuordnungsaktionen, die ghe-migrator
beim Übertragen von Daten ausführen kann:
action | BESCHREIBUNG | Entsprechende Modelle |
---|---|---|
import | (Standard) Daten von der Quellinstanz werden auf die Zielinstanz importiert. | Alle Datensatztypen |
map | Anstatt basierend auf den Quelldaten ein neues Modell zu erstellen, wird ein vorhandener Datensatz im Ziel verwendet. Dies ist nützlich zum Importieren eines Repositorys in eine vorhandene Organisation oder Zuordnen von Benutzeridentitäten im Ziel zu Benutzeridentitäten in der Quelle. | Benutzer, Organisationen, Projekte |
rename | Daten von der Quellinstanz werden umbenannt und anschließend auf die Zielinstanz kopiert. | Benutzer, Organisationen, Repositorys, Projekte |
map_or_rename | Bei Vorhandensein der Zielinstanz sollte die Zuordnung zur Zielinstanz erfolgen. Andernfalls sollte das importierte Modell umbenannt werden. | Benutzer |
merge | Daten von der Quellinstanz werden mit vorhandenen Daten auf der Zielinstanz kombiniert. | Teams, Projekte |
Es wird dringend empfohlen, die conflicts.csv-Datei zu überprüfen und ghe-migrator audit
zu verwenden, um sicherzustellen, dass die geeigneten Aktionen ausgeführt werden. Wenn alles wie gewünscht aussieht, können Sie fortfahren.
Migrationskonflikte beheben und benutzerdefinierte Zuordnungen einrichten
Wenn du der Meinung bist, dass ghe-migrator
eine nicht ordnungsgemäße Änderung vornimmt, kannst du Korrekturen vornehmen, indem du die Daten in conflicts.csv änderst. Du kannst an allen Zeilen in conflicts.csv Änderungen vornehmen.
Angenommen, du bemerkst, dass der Benutzer octocat
aus der Quelle im Ziel octocat
zugeordnet wird:
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/octocat | map |
Du kannst den Benutzer einem anderen Benutzer auf der Zielinstanz zuordnen. Angenommen, du weißt, dass octocat
im Ziel eigentlich monalisa
sein sollte. Du kannst die target_url
-Spalte in conflicts.csv so ändern, dass auf monalisa
verwiesen wird:
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/monalisa | map |
Weiteres Beispiel: Wenn du das octo-org/widgets
-Repository in octo-org/amazing-widgets
in der Zielinstanz umbenennen möchtest, ändere target_url
in octo-org/amazing-widgets
und recommend_action
in rename
.
model_name | source_url | target_url | recommended_action |
---|---|---|---|
repository | https://example-gh.source/octo-org/widgets | https://example-gh.target/octo-org/amazing-widgets | rename |
Benutzerdefinierte Zuordnungen hinzufügen
Während einer Migration geschieht es häufig, dass migrierte Benutzer andere Benutzernamen auf der Zielinstanz als auf der Quellinstanz besitzen.
Mit einer Liste der Benutzernamen von der Quellinstanz und einer Liste der Benutzernamen von der Zielinstanz kannst du eine CSV-Datei mit benutzerdefinierten Zuordnungen erstellen und anschließend anwenden, um sicherzustellen, dass der Benutzername und Inhalt jedes Benutzers am Ende einer Migration richtig zugeordnet werden.
Du kannst schnell eine CSV-Datei der migrierten Benutzer*innen im CSV-Format erstellen, die erforderlich ist, um benutzerdefinierte Zuordnungen mithilfe des ghe-migrator audit
-Befehls anzuwenden:
ghe-migrator audit -m user -g MIGRATION-GUID > users.csv
Nun kannst du diese CSV-Datei bearbeiten und die neue URL für jeden Benutzerin eingeben, die du zuordnen oder umbenennen möchtest. Aktualisiere dann die vierte Spalte, damit map
bzw. rename
entsprechend vorliegt.
Um beispielsweise den Benutzer octocat
in monalisa
im Ziel https://example-gh.target
umzubenennen, erstelle eine Zeile mit dem folgenden Inhalt:
model_name | source_url | target_url | state |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/monalisa | rename |
Mit demselben Prozess kannst du Zuordnungen für jeden Datensatz erstellen, der benutzerdefinierte Zuordnungen unterstützt. Weitere Informationen findest du in der Tabelle zu möglichen Zuordnungen für Datensätze.
Geänderte Migrationsdaten anwenden
-
Nachdem du Änderungen vorgenommen hast, verwende den Befehl
scp
, um deine bearbeitete conflicts.csv-Datei (oder eine beliebige andere .csv-Zuordnungsdatei im richtigen Format) auf die Zielinstanz anzuwenden:scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
-
Ordne die Migrationsdaten mithilfe des
ghe-migrator map
-Befehls neu zu. Übergib dazu den Pfad zu deiner bearbeiteten .csv-Datei und die Migrations-GUID:ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
-
Wenn der
ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
-Befehl berichtet, dass noch immer Konflikte bestehen, führe den Vorgang zum Beheben von Migrationskonflikten erneut durch.
Anwenden der importierten Daten auf GitHub Enterprise Server
-
Stellen Sie eine SSH-Verbindung mit Ihrer GitHub Enterprise Server-Zielinstanz her. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
ssh -p 122 admin@HOSTNAME
-
Starte den Importvorgang mit dem Befehl
ghe-migrator import
. du benötigst Folgendes:- Deine Migrations-GUID. Weitere Informationen finden Sie unter „Vorbereiten der migrierten Daten für den Import in GitHub Enterprise Server.“
- Dein personal access token für die Authentifizierung. Das von dir verwendete personal access token gilt nur für die Authentifizierung als Websiteadministrator und erfordert keinen bestimmten Bereich oder Berechtigungen. Weitere Informationen findest du unter Verwalten deiner persönlichen Zugriffstoken.
$ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN > Starting GitHub::Migrator > Import 100% complete /
- Um anzugeben, wo Migrationsdateien gestaget werden sollen, füge dem Befehl
--staging-path=/full/staging/path
an. Wird standardmäßig auf/data/user/tmp
festgelegt.
Migrationsdaten überprüfen
Mit ghe-migrator audit
wird standardmäßig jeder Datensatz zurückgegeben. Dadurch kannst du die Datensätze zudem filtern nach
- den Datensatztypen,
- dem Zustand der Datensätze.
Die Datensatztypen stimmen mit denen in den migrierten Daten überein.
Filter für Datensatztypen
Eintragstyp | Filtername |
---|---|
Benutzer | user |
Organisationen | organization |
Repositorys | repository |
Teams | team |
Meilensteine | milestone |
Projekte (klassisch) | project |
Probleme | issue |
Issue-Kommentare | issue_comment |
Pull Requests | pull_request |
Pull-Request-Reviews | pull_request_review |
Commit-Kommentare | commit_comment |
Pull-Request-Review-Kommentare | pull_request_review_comment |
Releases | release |
Bei Pull Requests oder Issues ergriffene Maßnahmen | issue_event |
Geschützte Branches | protected_branch |
Filter für Datensatzzustände
Datensatzzustand | BESCHREIBUNG |
---|---|
export | Der Datensatz wird exportiert. |
import | Der Datensatz wird importiert. |
map | Der Datensatz wird zugeordnet. |
rename | Der Datensatz wird umbenannt. |
merge | Der Datensatz wird gemergt. |
exported | Der Datensatz wurde erfolgreich exportiert. |
imported | Der Datensatz wurde erfolgreich importiert. |
mapped | Der Datensatz wurde erfolgreich zugeordnet. |
renamed | Der Datensatz wurde erfolgreich umbenannt. |
merged | Der Datensatz wurde erfolgreich gemergt. |
failed_export | Fehler beim Export des Datensatzes. |
failed_import | Fehler beim Import des Datensatzes. |
failed_map | Fehler beim Zuordnen des Datensatzes. |
failed_rename | Fehler beim Umbenennen des Datensatzes. |
failed_merge | Fehler beim Mergen des Datensatzes. |
Überwachte Datensätze filtern
Mit dem Befehl ghe-migrator audit
kannst du unter Verwendung des Flags -m
nach dem Datensatztyp filtern. Ebenso kannst du mit dem Flag -s
nach dem Importstatus filtern. Der Befehl sieht wie folgt aus:
ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID
Wenn du beispielsweise alle erfolgreich importierten Organisationen und Teams anzeigen möchtest, würdest du Folgendes eingeben:
$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed
Wir empfehlen dringend, jeden fehlgeschlagenen Import zu überprüfen. Dazu gibst du Folgendes ein:
$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed
Wenn Sie Bedenken in Bezug auf fehlgeschlagene Importvorgänge haben, können Sie sich unter GitHub Enterprise Support an uns wenden.
Abschließen des Imports in GitHub Enterprise Server
Nachdem deine Migration auf die Zielinstanz angewendet wurde und du die Migration überprüft hast, entsperrst du die Repositorys und löschst sie von der Quellinstanz. Vor dem Löschen deiner Quelldaten solltest du etwa zwei Wochen warten, um sicherzugehen, dass alles erwartungsgemäß funktioniert.
Repositorys auf der Zielinstanz entsperren
-
Melde dich über SSH bei Ihre GitHub Enterprise Server-Instance an. Wenn deine Instanz mehrere Knoten umfasst, wenn z. B. Hochverfügbarkeit oder Georeplikation konfiguriert ist, wird SSH im primären Knoten konfiguriert. Wenn du einen Cluster verwendest, kannst du SSH in einen beliebigen Knoten einfügen. Ersetzen Sie HOSTNAME durch den Hostnamen Ihrer Instanz bzw. durch den Hostnamen oder die IP-Adresse eines Knotens. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
Entsperre alle importierten Repositorys mit dem
ghe-migrator unlock
-Befehl. Du benötigst Deine Migrations-GUID:
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
Warning
Wenn dein Repository GitHub Actions-Workflows enthält, die den schedule
-Trigger verwenden, werden die Workflows nach einem Import nicht automatisch ausgeführt. Um die geplanten Workflows erneut zu starten, verschieben Sie einen Commit an das Repository. Weitere Informationen findest du unter Ereignisse zum Auslösen von Workflows.
Repositorys auf der Quellinstanz entsperren
Nach Abschluss der Migration sollten Sie die Repositorys für die Quelle entsperren.
Entsperren von Repositorys einer Organisation auf GitHub.com
Um die Repositorys einer GitHub.com-Organisation zu entsperren, sendest du eine DELETE
-Anforderung an den Endpunkt zum Entsperren der Migration. du benötigst Folgendes:
- Dein Zugriffstoken für die Authentifizierung
- Die eindeutige
id
der Migration - den Namen des zu entsperrenden Repositorys
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
-H "Accept: application/vnd.github.wyandotte-preview+json" \
https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock
Löschen von Repositorys aus einer Organisation auf GitHub.com
Nachdem du die Repositorys der GitHub.com-Organisation entsperrt hast, solltest du alle zuvor migrierten Repositorys mit dem Endpunkt zum Löschen von Repositorys löschen. du benötigst dein Zugriffstoken für die Authentifizierung:
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
https://api.github.com/repos/ORG-NAME/REPO_NAME
Repositorys auf einer GitHub Enterprise Server-Instanz entsperren
-
Melde dich über SSH bei Ihre GitHub Enterprise Server-Instance an. Wenn deine Instanz mehrere Knoten umfasst, wenn z. B. Hochverfügbarkeit oder Georeplikation konfiguriert ist, wird SSH im primären Knoten konfiguriert. Wenn du einen Cluster verwendest, kannst du SSH in einen beliebigen Knoten einfügen. Ersetzen Sie HOSTNAME durch den Hostnamen Ihrer Instanz bzw. durch den Hostnamen oder die IP-Adresse eines Knotens. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
Entsperre alle importierten Repositorys mit dem
ghe-migrator unlock
-Befehl. Du benötigst Deine Migrations-GUID:
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project