Jenkins – parte 2

jenkins-1_abertura

primeira parte consistiu basicamente em instalar e deixar o Jenkins minimamente configurado e, claro, funcionando. A parte de acesso a usuários permite usar diversos modos de autenticação (LDAP, usuários locais etc) enquanto os plugins consistem quase que em um universo a parte dentro do Jenkins.

Agora será a vez de efetivamente utilizá-lo para a criação de alguns build jobs, um primeiro para meramente testar o funcionamento da ferramenta e um outro cuidando de monitorar alterações no repositório do código fonte e se encarregar de compilá-lo.

Iniciando a máquina virtual

Antes de começar, claro, é preciso iniciar a máquina virtual onde está o Jenkins:

$ cd ~/Vagrant/jenkins
$ vagrant up

E aguardar alguns instantes até que a ferramenta esteja pronta para uso.

Build jobs

Execução dos build jobs (ou apenas jobs) é a principal tarefa do Jenkins. E eles tanto podem cuidar da compilação de um programa como também da execução de testes, integração com outros projetos, atualização de arquivos no repositório ou até mesmo disponibilização desta nova versão, ou novas versões, em um servidor web. Na verdade, como você pode executar diretamente trechos de código, é possível fazer de quase tudo.

Internamente o Jenkins também chama o build job de project (projeto) mas para evitar confusão, sempre que fizer referência a eles usarei build jobs, ou somente jobs para simplificar. Quanto usar projeto será para fazer referência a um projeto de software e/ou seu repositório.

Um um novo job

No painel do Jenkins, na página principal, selecione as opções create new jobs ou New Item, ambas irão para o mesmo local. Nomeie este item como “jenkins-example”, selecione Freestyle project e em seguida pressione o botão OK — que fica colado no rodapé da tela.

jenkins-2_new-item

Na página seguinte deixe Source Code Management marcado em none; em Build Trigers selecione Build periodically e coloque o agendamento (Schedule) como:

H/5 * * * *

Para terminar, em Build, vá em Add build step, escolha “Execute shell” e apenas escreva em comando (Command) o seguinte:

du ..

Daí pressione Save para finalizar a criação do job.

Mas o que tudo isto faz, melhor deverá fazer? Estou criando um job chamado “jenkins-example” que basicamente executará a cada 5 minutos, todos os dias, o comando du no diretório acima de onde o job é executado.

Claro que não é a coisa mais útil que se pode fazer com a ferramenta mas basta alguns minutos de espera para ver o Jenkins em operação:

jenkins-2_project-jenkins-example

No canto inferir esquerdo está o histórico de execuções e selecionando qualquer um deles e dentro dele a opção Console Output, estale está no canto superior esquerdo, é possível visualizar a saída da execução de cada comando du:

jenkins-2_console-output

Importante é que tanto a saída do comando como também seu status de execução estarão sendo guardados.

Este é um exemplo bem simples mas antes de seguir adiante selecione a opção Disable Project no canto superior direito para interromper a execução periódica dele.

Criando outro job

Agora algo mais interessante interligando Jenkins com Git e fazendo algo bem mais próximo de um projeto real de software. Mais uma vez vá em create new job/New Item, e nomeie-o como “git-example”, selecione mais uma vez Freestyle project e então OK.

jenkins-2_project-git-example.png

Na página seguinte marque Git em Source Code Management e indique o seguinte repositório:

https://github.com/plainspooky/jenkins.git

Logo abaixo, em Build Trigers, selecione Poll SCM e coloque o agendamento (Schedule) como:

H/5 * * * *

O Jenkins cuidará de a cada 5 minutos verificar se alguma alteração foi submetida no ramo “master” dentro deste repositório — Também é possível deixá-lo monitorando ramos específicos como  “teste”, “produção” para que ele cuide versões específicas do projeto.

Em Build, vá em Add build step, escolha “Execute shell” coloque os seguintes comandos em Command:

cd git-example
sh build

Daí é pressionar Save para finalizar a criação deste job.

Na página seguinte selecione o Build Now para executá-lo pela primeira vez e, claro, obter um erro de execução:

jenkins-2_project-git-example-build1

job não será executado corretamente! O motivo? Basta verificar o Console Output para saber a possível causa:

Started by user Giovanni Nunes
Building in workspace /var/lib/jenkins/workspace/git-example
Cloning the remote Git repository
Cloning repository https://github.com/plainspooky/jenkins.git
(...)
First time build. Skipping changelog.
[git-example] $ /bin/sh -xe /tmp/hudson7503439650128201568.sh
+ cd git-example
+ sh build
build: 5: build: gcc: not found
Build step 'Execute shell' marked build as failure
Finished: FAILURE

Está faltando o compilador! Deixei o erro acontecer como lembrança (óbvia) de que o ambiente em que o Jenkins é executado precisa ter todas as ferramentas, bibliotecas e permissões necessárias para tratar corretamente os arquivos do seu projeto.

Neste caso significa que é preciso instalar o GCC na máquina virtual:

$ vagrant ssh
ubuntu@ubuntu-xenial:~ sudo apt update && sudo apt install gcc

Também é importante acrescentar a instalação do GCC no script de provisionamento que é executado no “Vagrantfile” para torná-lo permanente (mais detalhes abaixo).

Daí basta novamente ir em Build Now :

jenkins-2_project-git-example-build2

E pronto, o programa example foi corretamente compilado — que é um pequeno programa que serve apenas para dizer quantos parâmetros foram passados a ele na linha de comando e cujo funcionamento será explorado na próxima parte.

Integração com o Git

O Jenkins possui um plugin para o GitHub que permite uma integração bem mais sofisticada com o serviço — ele aparece com a opção GitHub hook trigger for GITScm polling e que está logo acima do Poll SCM — mas para deixá-lo funcional seria necessário criar um token de acesso no GitHub etc. Assim preferi utilizar apenas o método mais simples de acesso ao repositório mas na documentação do plugin estão listados os passos necessários para esta configuração.

Vandalizando (de propósito) o código

Conforme foi configurado, a cada 5 minutos, o Jenkins se encarrega de verificar o repositório e em caso de alterações ele cuidará da compilação do programa (ou ao menos tentará compilá-lo).

Então é hora de vandalizar o código!

$ cd ~/Vagrant/jenkins
$ echo "ERRO" >> git-example/example.c
$ git add git-example/example.c
$ git commit -m "Código vandalizado"
$ git push

O resultado, claro, será um outro erro na execução no job:

jenkins-2_project-git-example-build3

Detalhe, ele exibirá o histórico das alterações submetidas no repositório que junto com as informações armazenadas em Console Output ajudarão a identificar mais rapidamente a causa do problema.

Fim desta parte…

Antes de terminar, aproveitei para corrigir o programa “example.c” e deixar o job rodar mais uma vez (o “Build #4”) antes de desabilitá-lo e desligar a máquina virtual com vagrant halt. Mas por enquanto o Jenkins está sendo utilizado como se fosse um cron glorificado e na próxima parte será a vez de sofisticar um pouco este uso.

Então, até!

Anúncios

Um comentário sobre “Jenkins – parte 2

  1. Pingback: Jenkins – parte 3 | giovannireisnunes

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s