DevSecOps

DevSecOps

[SmallTips] Rodando o GitLab CI Runner localmente

7 mai, 2018
Publicidade

Se há uma coisa que você deve fazer sempre, é manter sua suíte de testes. Para cada bug que você consertar e cada recurso novo, você deve adicionar novos testes.

Eu tenho trabalhado muito duro nas últimas semanas, literalmente codando sem parar, sete dias por semana. Lembra aquela coisa de “pare de reclamar, você não tem tempo. O que você faz da meia-noite às 6 da manhã?” Sim, não se aplica a mim.

E é exatamente quando você está privado do sono e exausto que você começa a adicionar erros. Mesmo que o seu código rode localmente, você irá atirar no próprio pé em uma daquelas sessões de programação às 3 horas da manhã. A suíte de testes era realmente minha parceira, co-piloto, trazendo-me de volta aos meus sentidos sempre que a noite ficava muito escura.

Eu mantenho meu próprio servidor personalizado GitLab para todos os projetos internos e de clientes da minha empresa. Apenas um pouco de paranoia para garantir que meu código seja apenas de minha propriedade. E o GitLab é uma ferramenta fantástica, ainda mais porque tem seu próprio companheiro de Integração Contínua. Basta adicionar seu arquivo .gitlab-ci.yml ao seu projeto, criar um novo ramo, enviá-lo e criar uma Merge Request que o CI entra em ação, com vários trabalhos paralelos, se desejar. Mesmo quando eu estava me esquecendo de rodar meus testes, o CI não me deixava falhar.

Manter um CI instalado e funcionando requer que você pare e mantenha suas especificações. Às vezes você vai se perguntar: “Por que um teste roda na sua máquina local, mas continua falhando no servidor de CI?” É aí que é super útil rodar a imagem do Docker de CI localmente para resolver as peculiaridades restantes, dependentes do ambiente.

E você pode fazer isso apenas rodando o próprio GitLab CI Runner. Ele pegará o .gitlab-ci.yml do seu projeto e o rodará localmente por meio do Docker, então qualquer problema que você esteja vendo no servidor, certamente acontecerá localmente também. Com o benefício adicional de você não precisar esperar na fila – existe uma fila de tarefas esperando para ser executada (muitos desenvolvedores trabalhando, não tantas máquinas para mastigar o trabalho de CI imediatamente). E você não será o único a adicionar trabalhos inúteis à mesma fila.

E, se você seguiu minhas recomendações e instalou a incrível distro Arch Linux (ou meu derivado favorito, Manjaro Gnome), você pode facilmente instalar o runner através do AUR assim:

pacaur -S gitlab-runner

Caso contrário, você terá que verificar suas reposições específicas de distro ou fazer o download do binário a partir daqui. Por exemplo:

wget https://gitlab-runner-downloads.s3.amazonaws.com/master/binaries/gitlab-runner-linux-amd64
sudo mv gitlab-runner-linux-amd64 /usr/local/bin
sudo chmod +x /usr/local/bin/gitlab-runner

Depois de instalá-lo, digamos que você tenha um snippet como este em sua configuração de .gitlab-ci.yml:

backend:
  stage: test
  script:
    - ./bin/cc-test-reporter before-build
    - bundle exec rspec --exclude-pattern "**/features/**/*_spec.rb"
  after_script:
    - ./bin/cc-test-reporter after-build --exit-code $? || true

Você pode configurar muitos trabalhos de teste para serem executados em paralelo. Eu recomendo que você separe testes JS relacionados ao frontend, testes unitários de backend minitest/Rspec, testes de recursos baseados em Capybara, verificações de segurança relacionadas ao Brakeman, por exemplo.

Cada um será executado em paralelo, e você não terá que esperar que tudo seja executado se estiver interessado apenas nos testes JS, por exemplo. Então você tem feedback mais rápido e pode começar a corrigir imediatamente.

Localmente, a partir do diretório raiz do seu projeto, basta rodar:

gitlab-runner exec docker backend

Naturalmente, isso pressupõe que você já tenha o Docker instalado e configurado corretamente. Se você não se certificar de ler a excelente entrada do Arch Wiki no Docker, basicamente é instalar o pacote Docker e adicionar-se ao docker group.

É isso! Super fácil. Mal chega a ser uma inconveniência e o runner fará tudo o que seu servidor GitLab CI está fazendo.

Uma ressalva é que, infelizmente, parece que você não tem a capacidade de salvar cache ou artefatos entre execuções de tarefas (gems, pacotes npm, etc). Então, toda vez que esse runner local for executado, ele começará do zero. Isso faz com que seja menos útil rodar o tempo todo, mas ainda é mais rápido do que empurrar para o servidor e esperar na fila pela sua vez em um servidor ocupado. Isso já me salvou algumas vezes.

***

Artigo traduzido com autorização do autor. Publicado originalmente em: http://www.akitaonrails.com/2018/04/28/smalltips-running-gitlab-ci-runner-locally