# Доступ к журналам миграции для GitHub Enterprise Importer

После выполнения миграции необходимо просмотреть журнал миграции, чтобы проверить наличие данных, которые не переносятся должным образом.

## Сведения о журналах миграции

Каждый раз, когда вы запускаете миграцию с GitHub Enterprise Importer, создаётся лог миграции. После каждой миграции необходимо проверить журнал миграции, чтобы просмотреть предупреждения о миграции.

В журнале миграции перечислены шаги, которые были выполнены в процессе миграции и содержат дополнительные сведения.

* Предупреждения о миграции, представляющие данные (например, проблемы, запросы на вытягивание или комментарии), которые не переносятся должным образом.
* Кто запустил миграцию
* Источник миграции
* Сколько времени занимает миграция

> \[!IMPORTANT]\
> Проблемы должны быть включены в целевом репозитории для создания журнала миграции.

Журнал миграции для миграции репозитория можно получить несколькими способами.

* На GitHub, просмотрев проблему «Журнал миграции» в мигрированном репозитории. Эту проблему можно использовать для обсуждения любых предупреждений с командой и записи любых решений.
* Скачав лог-файл с помощью GitHub CLI.

При миграции GitHub Enterprise Importer организации также создайте репозиторий с названием `gei-migration-results` в целевой организации. Этот репозиторий содержит сведения о миграции данных уровня организации и дублирует сведения в проблемах журнала миграции для каждого перенесенного репозитория.

Дополнительные сведения о интерпретации предупреждений в журнале миграции см. в разделе [Устранение неполадок при миграции с помощью GitHub Enterprise Importer](/ru/enterprise-server@3.18/migrations/troubleshooting/troubleshooting-your-migration-with-github-enterprise-importer#understanding-migration-log-warnings).

## Просмотр миграции репозитория в логе GitHub

Пользователи с доступом к репозиторию могут получить доступ к журналу миграции репозитория на GitHub.

1. Перейдите в перенесенный репозиторий в целевой организации.
2. В поле имени репозитория щелкните **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-issue-opened" aria-label="issue-opened" role="img"><path d="M8 9.5a1.5 1.5 0 1 0 0-3 1.5 1.5 0 0 0 0 3Z"></path><path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Z"></path></svg> Issues**.

   ![Снимок экрана: главная страница репозитория. На горизонтальной панели навигации вкладка с меткой "Проблемы" выделена темно-оранжевым цветом.](/assets/images/help/repository/repo-tabs-issues-global-nav-update.png)
3. Щелкните проблему с заголовком "Журнал миграции".

## Загрузка журнала миграции репозитория с помощью GitHub CLI

Владельцы организаций и члены организаций с ролью мигратора могут скачать логи миграции с помощью GitHub CLI.

С помощью команды можно скачать последний журнал миграции для отдельного репозитория `download-logs` . Точную команду зависит от источника миграции.

* [Загрузка журнала миграции репозитория с помощью ADO2GH extension](#downloading-a-repository-migration-log-with-the-ado2gh-extension)
* [Загрузка журнала миграции репозитория с помощью BBS2GH extension](#downloading-a-repository-migration-log-with-the-bbs2gh-extension)
* [Загрузка журнала миграции репозитория с помощью GEI extension](#downloading-a-repository-migration-log-with-the-gei-extension)

Журналы миграции доступны для скачивания в течение 24 часов после завершения миграции.

### Загрузка журнала миграции репозитория с помощью ADO2GH extension

Если источник миграции — Azure DevOps, можно скачать последний журнал миграции для отдельного репозитория с `gh ado2gh download-logs` помощью команды. Замените DESTINATION целевой организацией, РЕПОЗИТОРИЙ именем репозитория и FILENAME именем файла для скачанного файла.

```shell copy
gh ado2gh download-logs --github-target-org DESTINATION --target-repo REPOSITORY --migration-log-file FILENAME
```

* Если у вас еще нет `GH_PAT` переменной среды для personal access token с доступом к целевой организации, добавьте `--github-target-pat TOKEN`, заменив `TOKEN` personal access token.

* Если вы переносите данные GHE.com, добавьте `--target-api-url TARGET-API-URL`, где TARGET-API-URL является базовым URL-адресом API для поддомена предприятия. Например: `https://api.octocorp.ghe.com`.

### Загрузка журнала миграции репозитория с помощью BBS2GH extension

Если источник миграции — Bitbucket Server, можно скачать последний журнал миграции для отдельного репозитория с `gh bbs2gh download-logs` помощью команды. Замените DESTINATION целевой организацией, РЕПОЗИТОРИЙ именем репозитория и FILENAME именем файла для скачанного файла.

```shell copy
gh bbs2gh download-logs --github-target-org DESTINATION --target-repo REPOSITORY --migration-log-file FILENAME
```

* Если у вас еще нет `GH_PAT` переменной среды для personal access token с доступом к целевой организации, добавьте `--github-target-pat TOKEN`, заменив `TOKEN` personal access token. Для personal access token требований см. [Управление доступом к миграции с сервера Bitbucket](/ru/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server#required-scopes-for-personal-access-tokens).
* Если вы переносите данные GHE.com, добавьте `--target-api-url TARGET-API-URL`, где TARGET-API-URL является базовым URL-адресом API для поддомена предприятия. Например: `https://api.octocorp.ghe.com`.

### Загрузка журнала миграции репозитория с помощью GEI extension

Если ваш источник миграции — GitHub продукт, вы можете скачать последний журнал миграции для отдельного репозитория с помощью `gh gei download-logs` команды. Замените DESTINATION целевой организацией, РЕПОЗИТОРИЙ именем репозитория и FILENAME именем файла для скачанного файла.

```shell copy
gh gei download-logs --github-target-org DESTINATION --target-repo REPOSITORY --migration-log-file FILENAME
```

* Если у вас еще нет `GH_PAT` переменной среды для personal access token с доступом к целевой организации, добавьте `--github-target-pat TOKEN`, заменив `TOKEN` personal access token. Для personal access token требований см. [Управление доступом к миграции между продуктами GitHub](/ru/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#required-scopes-for-personal-access-tokens).
* Если вы переносите данные GHE.com, добавьте `--target-api-url TARGET-API-URL`, где TARGET-API-URL является базовым URL-адресом API для поддомена предприятия. Например: `https://api.octocorp.ghe.com`.

### Скачивание всех журналов миграции репозитория для скрипта миграции

Чтобы обеспечить доступ к журналам миграции для всех перенесенных репозиториев, можно использовать `--download-migration-logs` флаг при создании скрипта миграции для миграции репозиториев. При использовании этого флага скрипт будет включать `download-logs` команду для каждого репозитория, перенесенного в скрипт. Дополнительные сведения см. в разделе [Сведения о GitHub Enterprise Importer](/ru/enterprise-server@3.18/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer).

> \[!NOTE]
> Флаг можно использовать `--download-migration-logs` только с миграциями репозитория, а не с миграциями организации.

## Доступ к журналу миграции организации

Владельцы целевой организации могут получить доступ к журналу миграции организации на GitHub.

Чтобы получить доступ к журналу миграции для миграции организации, перейдите в репозиторий с именем `gei-migration-results` в целевой организации.

Файл `README.md` в корневом каталоге репозитория содержит следующие сведения о миграции организации:

* Любые предупреждения или ошибки, связанные с миграцией данных уровня организации, например параметров и команд
* Количество репозиториев, которые были успешно перенесены, и количество репозиториев, которые не удалось выполнить миграцию

`/success` Каталоги`/failure` содержат один файл для каждого репозитория, который успешно перенесен или не удалось выполнить миграцию соответственно. Эти файлы соответствуют соглашению `REPO_NAME.md`об именовании.

> \[!NOTE]
> Репозиторий `gei-migration-results` создается в начале процесса миграции, но обновляется только с помощью журналов миграции после завершения миграции.