Primeira Pipeline

Vamos criar nossa primeira pipeline, mas antes vamos fazer a seguinte configuração. Edite o runner que você configurou anteriormente e desmarque o opção untagged jobs. Se você esta seguindo o estudo, mantenha as mesmas tags pois será imporante mais tarde.

A opção untagged jobs quer dizer que somente jobs que tenham as tags general ou debian utilizaram o runner que criamos anteriomente. Se a tag não for passada será utilizados os runners shared. Vamos fazer essa experiência.

Criando projeto dentro do grupo. Use o blank project.

Clone o seu repositório e vamos criar o .gitlab-ci.yml vazio.

❯ git clone [email protected]:puziol/first-pipeline.git

Cloning into 'first-pipeline'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (3/3), done.

❯ cd first-pipeline

❯ ls
README.md

touch .gitlab-ci.yml

Atenção: Não é aceito gitlab-ci.yml nem .gitlab-ci.yaml. É PRECISO SER .gitlab-ci.yml e precisa estar na raiz do projeto.

Trabalhe no VSCode ou na sua IDE favorita. O que nos interessa é só falar do .gitlab-ci.yml por enquanto. Ainda não é a hora de entender o que é o que e sim de entender quem vai executar.

#.gitlab-ci.yml
test:
  script: "echo Hello World"

Salve e adicione tudo na branch padrão mesmo,suba o código e vamos ver o que acontece.

❯ git add .gitlab-ci.yml

❯ git cm "add gitlab-ci"  
[main bae0760] add gitlab-ci
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 .gitlab-ci.yml

❯ git push origin main

Verificando o repositório temos o pipeline rodando.

E depois completado.

Agora a pergunta é, quem executou? Em build > Pipelines temos a execução.

Clicando dentro do stage e depois em test podemos ver o log dessa exeução.

Foi usada uma imagem que não é a do runner que definimos e o fato de ter "blue-4.saas-linux-small-amd64" indica que é um runner SaaS do GitLab "runners-manager.gitlab.com" confirma que é gerenciado pelo próprio GitLab.

Mas agora eu quero que rode no runner auto hospedado que nós criamos.

Altere vamos alterar o .gitlab-ci.yml.

# Todos os jobs terão esta lista de tag caso não definido.
default:
  tags:
    - general

test:
  # Podemos definir as tags quando quisermos job por job.
  # tags:
  #   - debian
  script: "echo Hello World"

❯ git add .gitlab-ci.yml

❯ git cm "add gitlab-ci"  
[main bae0760] add gitlab-ci
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 .gitlab-ci.yml

❯ git push origin main

Quem rodou o job agora? Sim, o nosso runner.

Porém ele rodou com a imagem default, pois não definimos uma imagem.

Do mesmo modo que fizemos com as tags, poderíamos definir uma imagem default que seria utilizada todos os jobs ou podemos definir uma imagem diferente por job. Vamos substituir a imagem somente no job.

#.gitlab-ci.yml
default:
  tags:
    - fake # Não existe

test:
  tags:
    - debian #  Substituindo a tag para testar
  image: alpine
  script: "echo Hello World Alpine"

Subindo tudo.

❯ git add .gitlab-ci.yml
❯ git commit -m "test cicd com alpine"  
❯ git push origin main  

E temos o seguinte log.

Vamos fazer duas coisas agora ao mesmo tempo. Edite novamente o pipeline e marque untagged para esse pipeline.

Outra coisa que faremos será criar duas variáveis de nível de grupo. Vá em Settings > CI/CD > Variables.

A primeira variável será a VAR1 com o valor variable1 e vamos deixá-la como visible.

Em VAR2 vamos deixar como masked.

Já na VAR3 vamos deixar como masked e Hidden.

Veja que temos diferenças em como elas são mostradas na GUI.

Agora vamos ao projeto e veremos o que temos de variaveis. Podemos observar que temos as variáveis herdadas do grupo. Essa é uma das vantagens de utilizar grupos e subgrupos. Podemos declarar variáveis em cada grupo diferentes e ir acumulando variáveis declaradas.

O que acontece se declararmos a mesma variável? Vamos fazer isso para a VAR1 declarando novamente VAR1 em nível de projeto com o valor variable1new.

Observe que não podemos editar nenhuma variável herdada de um grupo no projeto. Somente teremos a permissão de leitura.

# Não vamos colocar a tag para ver o que acontece com o untagged
test:
  script:
  - echo $VAR1
  - echo $VAR2
  - echo $VAR3

❯ git add .gitlab-ci.yml  
❯ git commit -m "test variables and untagged"
❯ git push origin main  

Podemos observar que foi utilizado um shared runner do Gitlab SaaS. E as variavels masked foram respeitadas, sendo a única diferença do hidden em nível de amostragem no projeto. A mesma variável em nível de projeto sobreescreve a váriavel de grupo.

Agora a pergunta é... Por que o nosso runner não foi utilizado? Na verdade ele poderia ter sido utilizado, mas foi uma questão de sorteio.

Vamos ver o que eu tenho de runner nesse projeto disponível.

Se desabilitarmos os runner do GitLab no projeto o nosso runner ira atuar, mas não precisamos fazer isso em um projeto, podemos fazer isso em nível de grupo.

Uma coisa interessante é observar por que o GitLab esta nos entregando imagens do ruby como default. Os shared runners do GitLab.com rodam em ambientes gerenciados por eles — e muitos vêm com a imagem base ruby por padrão, porque o GitLab é feito em Ruby e eles assumem compatibilidade com muitos projetos.

Mesmo que seu projeto não tenha nada de Ruby, se você não especificar uma image: no .gitlab-ci.yml, o GitLab pode usar uma imagem default — que frequentemente é algo tipo ruby:2.x nos runners compartilhados.

Boa Prática sobre Runners

1. Sempre declare a imagem base. Mesmo que você saiba qual é a default, especifique no .gitlab-ci.yml. Isso evita surpresas se o padrão mudar no futuro. Coloque no topo do arquivo.

2. Use tags específicas para forçar o runner. Assim, mesmo que os shared runners do GitLab estejam disponíveis, seu runner será priorizado.

3. Use uma imagem personalizada com tudo que precisa. Se você tem liberdade pra escolher a imagem, monte uma com todas as dependências. Isso evita instalações desnecessárias e acelera o pipeline, faremos isso mais pra frente quando falarmos de performance.

4. Organize bem suas variáveis. As variáveis do GitLab são passadas como variáveis de ambiente para os runners. Coloque as que são comuns nos grupos e só mantenha as específicas no projeto. Assim, se precisar mudar algo global, não vai ter que editar projeto por projeto.

Outras dicas virão com o nosso aprendizado.

Hosted Gilab Runner

Como vimos sobre antes, podemos também utilizar o shared runners, mas podemos escolher runners no GitLab se não quisermos o nosso.