Gitolite

 (gitolite.com)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Gitolite hospeda repositórios Git em um servidor central e permite aplicar controle de acesso granular por repositório
  • Ao instalar via gerenciador de pacotes, costuma usar o nome gitolite3, e o código-fonte é disponibilizado no Codeberg e no GitHub
  • Se você já está familiarizado com Unix e SSH, pode usar a documentação de instalação rápida; se precisar de orientação passo a passo, siga o fluxo completo da documentação ou o guia de instalação à prova de erros
  • Erros de instalação/configuração e perda de chaves são tratados no documento emergencies, e problemas de segurança devem ser reportados diretamente por e-mail, enquanto o suporte geral usa a lista de discussão
  • O software é distribuído sob a GPL v2, e a documentação mantida separadamente usa, em princípio, a Creative Commons BY-NC-SA 3.0

Documentação de instalação e operação

  • Gitolite permite configurar repositórios Git em um servidor central e aplicar controle de acesso granular
    • O GitHub também pode ser usado como repositório-fonte alternativo
    • O nome do pacote no gerenciador de pacotes costuma ser gitolite3
  • Se você está familiarizado com Unix e SSH, pode consultar a instalação rápida
  • Se precisar de suporte passo a passo, siga exatamente o guia de instalação à prova de erros e, após a instalação, use os exemplos do cookbook para tarefas comuns
  • emergencies cobre problemas de instalação/configuração, recuperação de chaves perdidas, erros comuns ou raros e configurações não padrão que possam causar problemas

Canais de suporte e licença

  • Problemas de segurança devem ser reportados diretamente para sitaramc@gmail.com
  • Para suporte geral e discussões, use a lista de discussão no Google Groups
    • O primeiro e-mail de novos membros fica retido até ser aprovado, mas e-mails posteriores enviados do mesmo endereço não ficam retidos
    • Também há uma lista de discussão separada, de baixa frequência e unidirecional, para lançamentos e avisos de segurança
  • O suporte via IRC está disponível no canal #gitolite da libera.chat, e no canal #git também há usuários familiarizados com Gitolite
  • O software Gitolite é distribuído sob a GPL v2
    • A documentação usa, em princípio, a Creative Commons BY-NC-SA 3.0, mas contribuições externas podem ter uma licença separada indicada em cada arquivo
    • Os exemplos de código da documentação e os comentários relacionados podem ser considerados sob a GPL v2 se forem entendidos como não enquadrados em uso justo
  • GIT é uma marca registrada da Software Freedom Conservancy, e o nome Gitolite é usado conforme a licença

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários no Lobste.rs

  • Em 2013, foi implantado na Cambridge University um servidor Git baseado em gitolite e gitweb. A escolha foi feita porque parecia exigir muito menos tempo de administração do que o GitLab ou o Gitorious iniciais, e na prática foi basicamente isso mesmo.
    O gitolite tinha uma estrutura peculiar: executava comandos via SSH e gerenciava permissões de acesso por meio de um arquivo de configuração sofisticado, então a ausência de um console web de administração criava uma barreira de entrada. Foi criado um guia introdutório, mas ele só era adequado para usuários com confiança técnica.
    Como não havia nenhuma equipe alocada ao serviço Git, foi criado um serviço provisório no tempo livre, para comprovar a demanda e obter orçamento. Era difícil aceitar manter alterações locais de open source no SVN ou deixar repositórios Git em diretórios home que ninguém conseguia encontrar. Em relação à demanda por programação científica na universidade, faltava apoio de engenharia de software, e a visão era que os serviços centrais de TI deveriam apoiar o ensino e a pesquisa de toda a universidade, não se limitar ao uso interno.
    Com o recurso de delegação de gerenciamento de usuários, quase todo o gerenciamento de contas e suporte foi deixado a especialistas de cada grupo de pesquisa ou departamento. Por ser uma ferramenta difícil, ela acabou atraindo os early adopters técnicos pretendidos; havia bastante usuários, mas quase nenhuma solicitação de suporte. Também foi possível apoiar projetos envolvendo várias universidades, já que o acesso não era restrito a membros de Cambridge.
    O maior erro de avaliação foi não prever que o serviço provisório duraria cerca de 8 anos; depois ele foi substituído por um GitLab operado por uma equipe dedicada. A tarefa que mais consumiu tempo foi melhorar a resiliência, e a arquitetura que replicava os repositórios Git quase em tempo real para outro site provavelmente era complexa além do necessário.

    • Quando assumi esse serviço, a intenção era migrá-lo para um software forge que oferecesse integração contínua, repositórios de pacotes etc. À medida que o valor do software como resultado de pesquisa começou a ser reconhecido, também havia um clima favorável a investir orçamento em um serviço central da universidade.
      Foi justamente a época em que a Microsoft adquiriu o GitHub e em que se previu pela primeira vez o declínio do GitHub, então é interessante ver a história se repetindo. O GitLab ofereceu uma licença em condições muito vantajosas, e também havia a necessidade de uma demonstração interna aplicando Kubernetes e infraestrutura como código a serviços em nuvem. Hoje já saí da universidade, mas o GitLab ainda está em operação em https://gitlab.developers.cam.ac.uk/.
    • Em 2012–2013, um departamento de uma universidade local operava gitolite, usado principalmente por estudantes de engenharia de software. Era exagerado para o tamanho da base de usuários, mas, graças à simplicidade e às listas de controle de acesso granulares, era bom para gerenciar equipes e permissões de vários projetos dentro do departamento.
      Alguns anos depois, não havia mais ninguém para operá-lo e, com o GitHub se tornando muito popular, os usuários migraram do serviço interno da universidade para hospedagem externa. Eu achava que o projeto tinha desaparecido, então é bom ver que ele continua sendo mantido de forma constante.

  • Com as listas de controle de acesso granulares do gitolite, era possível permitir que certas chaves apenas clonassem repositórios, sem poder fazer push, ou permitir push, mas proibir force push. Era leve e prático; hoje eu provavelmente experimentaria https://github.com/djmdjm/gitlimit.

    • O código-fonte do Gitlimit é simples, então parece fácil estendê-lo com recursos como comandos personalizados.

  • Para projetos pessoais, Fossil também é adequado. Ele inclui um servidor web em um binário pequeno, pode ser servido de forma simples e, se necessário, também pode ser integrado a um repositório Git upstream.

    • O gitolite é uma ferramenta para múltiplos usuários que precisam de controle de acesso complexo e para hospedar vários repositórios.

  • No NRAO, também usamos gitolite por um tempo como solução provisória. Na época, a ferramenta com suporte oficial era o Subversion, mas o responsável pelo grupo o instalou para usuários internos que queriam Git. Não tinha muitos recursos, mas fazia bem o que era necessário.
    Hoje existe uma instalação do GitLab usada por todo o observatório, e há a possibilidade de migrar para GitHub ou GitLab, mas não sei qual será a decisão final. Passo muito tempo ajustando sistemas de integração e implantação contínuas, e não consigo imaginar uma forma de dar suporte a isso com gitolite ou de implementar fluxos de trabalho de pull/merge requests. Ainda assim, talvez a utilidade desses recursos seja exagerada.

  • Uso o fugit (https://github.com/cbdevnet/fugit), criado com o objetivo de extrema simplicidade, e gerencio os arquivos de configuração com um módulo Nix. É simples e eficaz; o gitolite sempre foi um pouco trabalhoso de usar.