Gerencie a visibilidade, as regras e as configurações do seu repositório
Os repositórios hospedam o código-fonte da aplicação e outros arquivos e são a construção central na qual os desenvolvedores criam software. Eles são usados para acessar métricas de segurança de aplicações, fluxos de trabalho de CI/CD e outras atividades diárias. Assim como existem controles e permissões nos níveis corporativo e organizacional, os repositórios oferecem controles para gerenciar o rastreamento de problemas, alterações propostas e revisões de código.
Para a Philips, a configuração da visibilidade padrão do repositório foi fundamental para a estratégia de aumentar a colaboração e o innersource.
Neste guia, você aprenderá:
Os tipos de visibilidade disponíveis para repositórios no GitHub para o seu modelo de usuário.
Como definir as condições para fazer o merge de pull requests usando rulesets.
Como usar configurações em nível de repositório para fornecer controles refinados além das restrições nos níveis de organização e corporação.
Visibilidade do repositório
Há três tipos de visibilidade para repositórios: públicos, internos e privados.
Repositórios públicos são visíveis para o mundo e são usados principalmente para conteúdo de código aberto.
Repositórios internos têm acesso de leitura para todos os membros plenos da conta Enterprise (não para colaboradores externos).
Repositórios privados são visíveis apenas para indivíduos ou equipes que receberam acesso explícito, incluindo por meio de permissões de base organizacional ou corporativa.
Administradores podem visualizar todos os repositórios das corporações e organizações, independentemente da visibilidade, e podem alterar as configurações de visibilidade de um repositório. Administradores de repositório, no entanto, não podem alterar a configuração de visibilidade de um repositório, a menos que seja permitido por uma política explícita.
Observação: alterar a visibilidade do repositório pode ter alguns efeitos posteriores se você usar fork ou outros recursos. Revise o impacto de uma alteração de visibilidade do repositório antes de fazer uma alteração.
Empresas que usam Enterprise Managed Users (usuários gerenciados por empresas, EMUs) impedem a criação de repositórios públicos ou alteram a visibilidade de qualquer repositório existente para público.
Em nossa organização principal do GitHub, definimos a visibilidade do repositório padrão como interna para promover o innersource, melhorando a descoberta de código para reutilização. É claro que há motivos pelos quais você pode não querer que um repositório fique totalmente visível para todos, por isso permitimos que os repositórios sejam definidos como privados, mas eles precisam primeiro solicitar uma exceção.
Rulesets e capacidade de merge de pull requests
Rulesets são grupos de regras que, entre outras coisas, estabelecem políticas e definem controles sobre quem, quando, como e sob quais condições um pull request pode fazer o merge. Eles podem ser definidos por repositório, conjunto de repositórios ou para organizações inteiras, e vários rulesets podem ser aplicados ao mesmo tempo e são avaliados usando camadas de regras. Quando as condições de capacidade de merge são definidas, não basta que o usuário tenha apenas permissão de escrita para um repositório; ele também deve atender a todas as condições de capacidade de merge para que o pull request faça o merge e se torne parte da base de código.
Algumas das condições que os rulesets podem verificar incluem:
Exigir que as implantações sejam bem-sucedidas antes de fazer o merge
Exigir que as verificações de status sejam aprovadas antes de fazer o merge
Qualquer pessoa com acesso de leitura a um repositório pode visualizar quais rulesets estão ativamente aplicados a esse repositório a qualquer momento. Portanto, é possível verificar o status de restrição de um repositório sem acesso adicional e saber quais restrições seriam aplicadas se uma alteração fosse solicitada.
As regras podem ser definidas para o status “evaluate” na criação para verificar como elas seriam aplicadas antes de começar a usá-las. A página de insights de regras fornece uma visão de quais ações do usuário seriam afetadas pelas regras do modo de avaliação.
Se você usa o GitHub há algum tempo, talvez também conheça as regras de proteção de branch. As regras de proteção de branch são um método legado de controle de capacidade de merge. As regras de proteção de merge existentes podem ser combinadas com rulesets, mas os rulesets são mais flexíveis e funcionais e são o método preferido de controle de capacidade de merge para o GitHub daqui para frente.
Criamos um bot usando o GitHub Actions para verificar todos os nossos repositórios e garantir que eles tenham um arquivo YAML designando o proprietário, os níveis de permissão e outras características semelhantes. Se o arquivo não for encontrado, o bot cria automaticamente um problema para pedir à equipe para criá-lo. Dessa forma, podemos permitir que as equipes utilizem o innersource por padrão, em vez de impedi-las por padrão.
Configurações de repositório
Algumas das mesmas configurações vistas nos níveis de corporação e organização, incluindo políticas do GitHub Actions, políticas e ativação de recursos de segurança e configurações de criação de fork, estão disponíveis no nível de repositório individual. Também é possível habilitar e desabilitar recursos como Issues, GitHub Discussions, e projetos legados (“clássicos”) em cada repositório, que pode ser útil quando você precisa limitar o uso de repositórios específicos, como durante implementações de recursos ou ao arquivar conteúdo.
Para configurações no nível de repositório, elas devem ser definidas para serem mais restritivas do que configurações ou políticas corporativas ou organizacionais. Por exemplo, se a política corporativa ou organizacional estiver definida para não permitir a criação de fork, não será possível permitir a criação de fork por repositório. No entanto, se a política da sua corporação ou organização permitir o uso de qualquer ação, é possível definir uma política por repositório para apenas permitir o uso de uma lista especificada de ações permitidas nesse repositório.
A seguir: Use equipes, funções e usuários para gerenciar o acesso aos repositórios
Agora que definimos muitas das configurações fundamentais nos níveis de corporação, organização e repositório, é hora de subdividir ainda mais o acesso e recriar estruturas corporativas refinadas usando equipes e funções de usuário.
Recursos adicionais:
A regras de repositório do GitHub agora estão disponíveis para todos (uma visão geral de como usar rulesets)