CI mínima com hooks do Git e nq

• Uma configuração simples de CI que automatiza testes, build e movimentação de arquivos adicionando um hook post-receive a um repositório Git bare em um servidor pessoal
• Em comparação com CIs existentes, com configurações YAML complexas, execução lenta e auto-hospedagem difícil, não havia necessidade de isolamento completo de build nem de gerenciamento de segredos
• Se as tarefas forem executadas diretamente no hook, um push pode ser rejeitado em caso de falha ou sua conclusão pode ser atrasada, então o processamento é feito em segundo plano com a fila mínima de tarefas nq
• O hook chama apenas o nq, e os logs podem ser verificados com ssh server nqtail -a, permitindo uma operação rápida e simples
• Conforme a necessidade, é possível isolar builds com landdown·Podman, gerenciar segredos com sops, ou expandir o fluxo de desenvolvimento com patches Git por e-mail, git-shell e git http-backend

---

Configuração de post-receive hook e nq

• Em um servidor pessoal, cria-se o repositório com ssh server git init --bare repo e faz-se o clone com git clone server:repo
• Coloca-se um post-receive hook em forma de script shell no diretório hooks do repositório bare para iniciar a CI a cada push
• Executar as tarefas diretamente no hook gera dois problemas
  • Se o script falhar, o push é rejeitado
  • Se a execução do script for lenta, a conclusão do push também atrasa
• No hook, chama-se a fila mínima de tarefas nq para adicionar o trabalho a uma fila em segundo plano
  • Os logs são verificados com ssh server nqtail -a
  • O processo de configuração pode ser visto em um tutorial curto

Isolamento e expansão do fluxo de desenvolvimento

• Para executar builds em um sandbox, é possível usar landdown
• É possível isolar builds do ambiente do host com Podman ou gerenciar segredos com sops
• Para desenvolvimento no estilo bazaar, uma configuração que recebe patches Git por e-mail é adequada
• Para desenvolvimento no estilo cathedral, é possível configurar com git-shell ou git http-backend

[GN⁺]

Comentários no Lobste.rs

• CI tem pelo menos dois problemas
  O problema fácil é executar make test quando o código muda; o difícil é executar make test em Linux, Windows e Mac

  • Linux é fácil e Windows é difícil, mas macOS é doloroso num outro nível
  • A parte difícil em CI, na minha visão, é o motor de execução de jobs que também dá suporte à depuração quando algo falha
    Sempre me incomodou que a experiência do desenvolvedor e os recursos de depuração desses motores existentes ficassem em segundo plano, então estou criando um sistema de CI em https://ci.pico.sh. Também não gosto de DSL, e YAML encadeado em camadas dá a sensação de estar sugando lentamente a sua alma
  • Essa abordagem resolve o problema fácil, e talvez possa ser estendida para suportar a família BSD com QEMU e várias distribuições com Docker, mas além disso parece ser preciso uma ferramenta mais completa

• Já construí isso em cima do gitolite e passei para o Temporal para controlar o processo de build sem limitações
  Dá até para rejeitar o push quando a execução falha, mas em geral eu deixava o hook passar e tratava a falha separadamente; a configuração era simples e divertida

  • Gosto especialmente das ferramentas de controle de acesso do gitolite, e também é excelente poder criar um novo repositório fazendo push para um repositório que não existe

• Outro CI mínimo centrado na execução de shell scripts é o laminar CI, que também oferece uma interface web

• Há muito tempo, em um ambiente corporativo só com Windows, deixávamos um Mac mini como servidor de CI local usado pelo time inteiro para compilar apps iOS, e essa foi uma das primeiras formas de usar Git que testamos

• Encontrei em https://mccd.space/git/ , e parece que usa um fork do stagit
  Até alguns meses atrás eu rodava Forgejo e Woodpecker, mas a maioria dos recursos não era necessária, então removi tudo e estava procurando uma configuração mais leve como esta. O próximo item da lista era CI, então caiu em ótima hora, e agora estou pensando se vou espelhar uma pequena biblioteca que devo publicar em breve no SourceHut

  • Fiz um fork do stagit para adicionar e-mail de contato e uma barra de navegação, incluí IDs para alterar o CSS e removi informações desnecessárias
    O repositório é exposto na web em modo somente leitura com git-daemon, e deixei toda a forma de configurar isso documentada aqui

• Conheci o nq por causa deste post, mas provavelmente vou usar systemd-run
  Como uso Nix em praticamente todos os executores, talvez dê para resolver os requisitos de CI com o sistema de monitoramento expondo os resultados de nix flake check como métricas e logs OTLP

• Gosto desse tipo de configuração simples de plataforma de desenvolvimento self-hosted
  Dá para configurar e usar facilmente o bubblewrap, que é um sistema de contêineres leve e simples, para CI. Só que, se usar nq, parece impossível rejeitar o push quando o CI falha, então fiquei curioso sobre como isso é tratado

  • Também há uma ferramenta auxiliar que usa Landlock para restringir scripts, e acho o uso um pouco mais simples
    Se precisar de mais isolamento, dá para adicionar Podman, Docker ou bubblewrap. Eu não rejeito push quando o CI falha pelo mesmo motivo de não ter um hook pré-commit que execute os testes: às vezes você precisa fazer commit ou push de algo quebrado, e o push pode ficar muito lento. Se precisar rejeitar, basta executar o CI de forma síncrona sem nq e bloquear o push quando o código de saída não for 0
    Ou então dá para executar com nq em branches que não sejam a main e deixar apenas a branch main em execução síncrona

• Parece que o link de landdown está quebrado

  • Vou corrigir quando chegar em casa; o endereço correto é https://mccd.space/git/landdown/file/README.html