# Dados migrados para migrações dinâmicas do GitHub Enterprise Server para o GHE.com

Quais dados e atualizações dinâmicas estão incluídos em uma migração ao vivo?

>[!NOTE] 
Enterprise Live Migrations está dentro prévia pública e sujeito a alterações.

## Dados que são migrados

ELM migra quase todos os dados no nível do repositório. Recursos de nível de organização, como equipes, projetos e configurações de organizações e webhooks, são excluídos da migração e devem ser configurados manualmente no destino.

A única ação no nível da organização com suporte pelo ELM é a criação de uma conta alvo da organização, caso esta ainda não exista.

### Configuração e configuração do repositório

| Resource | Notes |
|---|---|
| Metadados e configurações do repositório | Visibilidade, descrição, branch padrão e recursos habilitados |
| Webhooks do repositório | Configurações de webhook para o repositório |
| Tópicos do repositório | Marcas para categorizar o repositório |
| Configurações de PR do repositório | Configurações de mesclagem e revisão de solicitação de pull |
| Configurações de ações | Configuração de GitHub Actions no nível do repositório, incluindo ações e permissões permitidas |
| Links automáticos | Referências de autolink personalizadas |
| Proteções de ramificação | Regras de proteção de branch |
| Páginas | Configuração do GitHub Pages |

### Dados do Git, LFS e wikis

| Resource | Notes |
|---|---|
| Repositório Git (refs, objetos, histórico) | Inclui todos os refs, objetos e histórico de commits. O repositório é mantido atualizado sobre o destino durante toda a migração. |
| Objetos LFS | Objetos de Armazenamento de Arquivos Grandes do Git. Requer que o LFS seja habilitado na instância de origem GitHub Enterprise Server . |
| Wiki | O repositório Git wiki |

### Problemas, comentários e reações

| Resource | Notes |
|---|---|
| Problemas | Inclui estado, atribuições e corpo |
| Comentários dos problemas | Todos os comentários sobre problemas |
| Reações a issues | Reações sobre problemas |
| Emitir reações de comentário | Reações em comentários de questões |
| Etiquetas de questões | Associações de rótulos em problemas |
| Eventos de problema | Eventos da linha do tempo (atribuídos, rotulados, fechados etc.) |
| Fechar referências de questões | Referências cruzadas que fecham problemas (por exemplo, "corrige #123") |

### Solicitações de pull, revisões e threads

| Resource | Notes |
|---|---|
| Solicitações de pull | Inclui o estado, revisores, conteúdo e status do rascunho |
| Revisões de PR | Revisões enviadas, incluindo estados aprovados, solicitados por alterações e com comentários |
| Comentários de revisão de PR | Comentários de revisão de código em linha |
| Threads de revisão de PR | Discussões encadeadas, incluindo situação resolvida e não resolvida |
| Reações a comentários em PR | Reações em comentários de revisão de pull request |
| Rótulos de PR | Associação de rótulos em pull requests |

### Rótulos, marcos importantes, versões e Integração Contínua (CI)

| Resource | Notes |
|---|---|
| Rótulos | Definições de rótulo, incluindo nome, cor e descrição |
| Fases | Definições de marcos e estado |
| Lançamentos | Metadados de versão, incluindo tag, nome, corpo e status de pré-lançamento ou rascunho |
| Reações ao lançamento | Reações sobre lançamentos |
| Comentários de commit | Comentários sobre confirmações individuais |
| Verificações de status de commit | Verificações de status de CI/CD em commits |
| Execuções de verificação | Verificar os resultados da execução |
| Conjuntos de verificações | Verificar agrupamentos de pacotes |
| Permissões de repositório de equipe | Associações de permissão de equipe para repositório |

### Ativos binários e anexos de arquivo

| Resource | Notes |
|---|---|
| Recursos de lançamento | Ativos binários anexados a lançamentos, até 2 GB por ativo |
| Attachments | Anexos de arquivos de imagem e vídeo incorporados em corpos de pull requests e issues |
| Arquivos de repositório (anexos que não são de mídia) | Anexos de arquivos que não são de mídia, como PDFs e arquivos de texto, associados a problemas e solicitações de pull |

### Usuários e manequins

| Resource | Notes |
|---|---|
| Manequins | Cada usuário do GitHub Enterprise Server referenciado em dados migrados é representado como um manequim: uma identidade de espaço reservado sem filiação à organização ou acesso ao repositório. Após a conclusão da migração, você pode recuperar manequins associando-os a contas de usuário reais. |

## Dados que não são migrados

### Dados do repositório

| Dados | Notes |
|---|---|
| Padrões de repositório | N/A |
| Conjuntos de regras do repositório | Somente as regras de proteção de branch são migradas. |
| Solicitações de pull de bifurcações | N/A |
| Solicitações de pull pendentes para revisão | Somente as revisões enviadas são migradas. |

### Dados da organização

Os dados no nível da organização, como os seguintes, **não** são migrados:

* Settings
* Equipes
* Projetos
* Webhooks

## Eventos incluídos em atualizações ao vivo

Após a conclusão do backfill inicial, o monitor de **eventos** do exportador monitora os webhooks GitHub Enterprise Server para capturar as alterações em andamento e encaminhá-las para o serviço de migração na empresa alvo.

As tabelas a seguir documentam quais tipos de recursos dão suporte a atualizações dinâmicas e quais ações de webhook são tratadas.

| Tipo de recurso | Eventos suportados | Eventos sem suporte |
|---|---|---|
| **Repository** | `edited` | 
`archived`, `deleted`, `privatized`, `publicized`, , `renamed`, `transferred`, `unarchived` |
| **Problemas** | 
`assigned`, `closed`, `edited`, `labeled`, `opened`, , `reopened`, `unassigned`, , `unlabeled`, `milestoned`, `demilestoned` | 
`deleted`, `locked`, `pinned`, `transferred`, `unlocked`, , `unpinned` |
| **Emitir comentário** | 
`created`, `edited` | `deleted` |
| **Solicitação de pull** | 
`assigned`, `closed`, `converted_to_draft`, `edited`, `labeled`, `opened`, `ready_for_review`, `reopened`, `unassigned`, `unlabeled`, `milestoned`, `demilestoned` | 
`auto_merge_disabled`, `auto_merge_enabled`, `dequeued`, `enqueued`, , `locked`, `review_request_removed`, `review_requested`, , `synchronize``unlocked` |
| **Revisão de solicitação de pull** | 
`edited`, `submitted` | `dismissed` |
| **Comentário de revisão de solicitação de pull** | `edited` | 
`created`, `deleted` |
| **Thread de revisão de solicitação de pull** | 
`resolved`, `unresolved` | N/A |
| **Rótulo** | `created` | 
`deleted`, `edited` |
| **Lançamento** | 
`created`, `edited`, `prereleased`, `published`, `released`, , `unpublished` | `deleted` |
| **Marco** | 
`closed`, `created`, , `edited``opened` | `deleted` |
| **Regra de proteção de ramo** | 
`created`, `edited` | `deleted` |
| **Comentário de confirmação** | 
`created`, `edited` | `deleted` |
| **Montagem de página** | Todas as ações | N/A |
| **Confirmar verificações de status** | Todas as ações | N/A |
| **Wiki** | Todas as ações | N/A |
| **Autolink** | 
`created`, `deleted` | N/A |
| **Fechar referência de problema** | `created` | N/A |
| **Reação** | 
`created`, `deleted` | N/A |
| **Configurações de ações do repositório** | `updated` | N/A |
| **Webhook do repositório** | 
`created`, `updated` | N/A |

> [!NOTE]
> Quando uma revisão de solicitação de pull é enviada, ELM importa a revisão completa, incluindo todos os comentários embutidos. Os comentários embutidos que fazem parte de um envio de revisão inicial são migrados corretamente. No entanto, **as respostas adicionadas a um thread de revisão após o envio da revisão** não são capturadas como atualizações dinâmicas e não aparecerão no repositório migrado.

## Dados não incluídos em atualizações dinâmicas

Os seguintes são exportados somente durante o backfill inicial e **não** são atualizados por webhooks:

* Execuções de verificação
* Conjuntos de verificações
* Configuração do GitHub Pages

## Reformulação de links e menções

As referências **dentro do repositório de origem**, como menções de usuário ou links para problemas e solicitações de pull no mesmo repositório, são reescritas para que ainda apontem para os recursos corretos após a migração.

As referências a **repositórios diferentes** (como um link para um problema no repositório `repo-2` de um pull request em `repo-1`) **não** são migradas e apontarão para exatamente o mesmo destino após a migração. Isso se aplica mesmo que o repositório referenciado já tenha sido migrado ou esteja sendo migrado simultaneamente.