Skip to main content

Painel de administração do site

Você pode usar o painel de administração do site para gerenciar usuários, organizações e repositórios no sua instância do GitHub Enterprise Server.

Para acessar o painel, clique em no canto superior direito de qualquer página.

Explorar

Os dados da página de tendências do GitHub são calculados em períodos diários, semanais e mensais para repositórios e desenvolvedores. Você pode ver quando esses dados foram armazenados em cache pela última vez e colocar na fila novos trabalhos de cálculo de tendências na seção Explorar.

Relatórios

Caso você precise obter informações sobre os usuários, as organizações e os repositórios do sua instância do GitHub Enterprise Server, normalmente, busque dados JSON por meio da API do GitHub. Infelizmente, a API pode não fornecer todos os dados necessários e ainda requer um pouco de conhecimento técnico. O painel de administração do site oferece uma seção Relatórios como alternativa, facilitando o download de relatórios CSV com a maioria das informações de que você provavelmente precisará para usuários, organizações e repositórios.

Especificamente, é possível baixar relatórios CSV que listem o seguinte:

  • todos os usuários;
  • todos os usuários ativos
  • todos os usuários inativos
  • todos os usuários suspensos;
  • todas as organizações;
  • todos os repositórios.

Você também pode acessar esses relatórios de forma programática pela autenticação HTTP padrão com uma conta de administrador do site. Você deve usar um personal access token com o escopo site_admin. Para obter mais informações, confira "Gerenciar seus tokens de acesso pessoal".

Por exemplo, veja abaixo uma forma de baixar o relatório "todos os usuários" com um comando curl:

curl --remote-name \
     --location \
     --user 'USERNAME:TOKEN' \
     http(s)://HOSTNAME/stafftools/reports/all_users.csv

Para acessar os outros relatórios por meio de programação, substitua all_users por active_users, dormant_users, suspended_users, all_organizations ou all_repositories.

Observação: a solicitação curl inicial retornará uma resposta HTTP 202 se não houver relatórios armazenados em cache disponíveis. Um relatório será gerado em segundo plano. Você pode enviar uma segunda solicitação para baixar o relatório. Você pode usar uma senha ou um token OAuth com o escopo site_admin no lugar de uma senha.

Relatórios de usuário

ChaveDescrição
created_atMomento da criação da conta do usuário (carimbo de data/hora ISO 8601)
idID da conta de usuário ou organização
loginNome de login da conta
emailEndereço de e-mail principal da conta
roleConta de administrador ou usuário regular
suspended?Se a conta foi suspensa
last_logged_ipEndereço IP mais recente a fazer login na conta
reposNúmero de repositórios pertencentes à conta
ssh_keysNúmero de chaves SSH registradas na conta
org_membershipsNúmero de organizações às quais a conta pertence
dormant?Se a conta está inativa
last_activeÚltima vez em que a conta ficou ativa (carimbo de data/hora ISO 8601)
raw_loginInformações brutas de login (formato JSON)
2fa_enabled?Se o usuário habilitou a autenticação de dois fatores

Relatórios da organização

ChaveDescrição
idID da organização
created_atMomento de criação da organização
loginNome de login da organização
emailEndereço de e-mail principal da organização
ownersNúmero de proprietários da organização
membersNúmero de integrantes da organização
teamsNúmero de equipes da organização
reposNúmero de repositórios da organização
2fa_required?Se a organização exige autenticação de dois fatores

Relatórios do repositório

ChaveDescrição
created_atMomento de criação do repositório
owner_idID do proprietário do repositório
owner_typeSe o repositório pertence a um usuário ou organização
owner_nameNome do proprietário do repositório
idID do repositório
nameNome do repositório
visibilitySe o repositório é público ou privado
readable_sizeTamanho do repositório em formato legível por humanos
raw_sizeTamanho do repositório como número
collaboratorsNúmero de colaboradores do repositório
fork?Se o repositório é uma bifurcação
deleted?Se o repositório foi excluído

Indexação

Os recursos de pesquisa do GitHub da plataforma Elasticsearch. Esta seção do painel de administração do site mostra o status atual do seu cluster do Elasticsearch e oferece várias ferramentas para controlar o comportamento de pesquisa e do índice.

Para obter mais informações sobre a pesquisa de código, confira "Pesquisa na documentação do GitHub". Para obter informações sobre o Elasticsearch, visite o site do Elasticsearch.

Observação: em uso normal, os administradores do site não precisam criar índices ou agendar trabalhos de reparo. Para solução de problemas ou outras finalidades de suporte, o Suporte do GitHub pode instruir você a executar um trabalho de reparo.

Gerenciamento de índice

GitHub Enterprise Server reconcilia o estado do índice de pesquisa com os dados na instância de maneira automática e regular.

  • Problemas, solicitações de pull, repositórios e usuários no banco de dados
  • Repositórios Git (código-fonte) no disco

Sua instância usa trabalhos de reparo para reconciliar os dados e agenda um trabalho de reparo em segundo plano quando ocorrem os eventos a seguir.

  • Um índice de pesquisa é criado.
  • Dados ausentes precisam ser provisionados.
  • Dados antigos de pesquisa precisam ser atualizados.

Você pode criar um índice ou clicar em um índice existente na lista para gerenciá-lo. É possível executar as operações a seguir em um índice.

  • Torne o índice pesquisável.
  • Torne o índice gravável.
  • Atualize o índice.
  • Excluir o índice
  • Redefina o estado de reparo do índice.
  • Inicie um novo trabalho de reparo de índice.
  • Habilite ou desabilite trabalhos de reparo de índice.

Uma barra de progresso mostra o status atual de um trabalho de reparo em todos os trabalhadores em segundo plano. A barra é a diferença percentual do deslocamento do reparo com o ID de registro mais alto no banco de dados. Você pode ignorar o valor mostrado na barra de progresso após a conclusão de um trabalho de reparo. A barra de progresso mostra a diferença entre o deslocamento de reparo e a ID de registro mais alta no banco de dados, e diminuirá à medida que mais repositórios forem adicionados ao sua instância do GitHub Enterprise Server, mesmo que esses repositórios estejam realmente indexados.

Para minimizar os efeitos no desempenho de E/S e reduzir as chances de exceder o tempo limite das operações, execute o trabalho de reparo fora dos horários de pico. À medida que o trabalho reconciliar o índice de pesquisa com os dados de banco de dados e repositório Git, uma CPU será usada. Monitore as médias de carga do sistema e o uso da CPU com um utilitário como top. Se você não observar nenhum aumento significativo no consumo de recursos, também deverá ser seguro executar um trabalho de reparo de índice durante o horário de pico.

Os trabalhos de reparo usam um "deslocamento de reparo" a fim de alcançar a paralelização. Trata-se de uma compensação na tabela do banco de dados para o registro a ser reconciliado. Vários trabalhos em segundo plano podem sincronizar tarefas com base nessa compensação.

Esta ação permite habilitar ou desabilitar as operações de pesquisa e índice no código-fonte.

Logins reservados

Certas palavras são reservadas para uso interno em sua instância do GitHub Enterprise Server, o que significa que essas palavras não podem ser usadas como nomes de usuário.

Por exemplo, as palavras a seguir são reservadas, entre outras:

  • admin
  • enterprise
  • login
  • staff
  • support

Para a lista completa ou palavras reservadas, acesse "Logins reservados" no painel de administração do site.