GitLab - Cache Dependencies

Douglas Fernandes
bawilabs
Published in
3 min readFeb 8, 2019

O objetivo desse artigo é conceituar os termos cache, cache dependencies e como utilizá-lo no GitLab CI/CD para otimizar a duração do build .

Cache nada mais é do que uma área da memória onde é mantida uma cópia temporária de dados oriundos de um acesso mais lento, com o objetivo de acelerar a recuperação dos dados.

Durante o processo de desenvolvimento de software é muito comum a utilização de libraries que são buscadas via internet durante o build . Cache Dependencies nada mais é do que fazer um cache dessas libraries .

O GitLab CI/CD fornece esse recurso nativamente ao desenvolvedor desde a versão 9.0 . Que oferece ao desenvolvedor um mecanismo para armazenar dados de um pipeline e otimizar a duração de um job reutilizando o cache do job anterior. Não confundir cache com artifacts , atualmente o GitLab suporta ambos, mas eles são bem diferentes. Enquanto o cache é utilizado para otimizar invocações subsequentes de dependências (npm packages, go vendors, etc) e pode ser buscado somente do mesmo runner; artifacts deve ser utilizado para armazenar arquivos compilados (jar, apk, etc) e pode ser buscados de vários runners .

Como utilizar Cache Dependencies no GitLab CI/CD?

Para utilizar Cache Dependencies durante o build no GitLab CI/CD basta adicionar a tag cacheno arquivo .gitlab-ci.yml como o exemplo a seguir:

cache:  paths:    - ${CI_PROJECT_DIR}/downloads    - ${CI_PROJECT_DIR}/go

Ao término do job todos os arquivos contidos nos diretórios especificados serão armazenados no cache .

Conclusão

Utilizando desse recurso há uma grande redução na duração do build . O job que utilizava Cache Dependencies foi 68 segundos mais rápido como mostra a imagem a seguir:

Comparativo entre jobs que utilizam cache. Da esquerda para direita, sem cache e utilizando cache.

Atualmente o GitLab oferece 2000 minutos de pipelines grátis, utilizando o cache há uma considerável redução na duração de cada job .

Considerando que cada repositório de código efetua 3 steps (unit-test, deploy-staging, deploy-production), sem utilizar cache será possível 11 builds por dia em contra partida ao utilizar cache esse número saltaria para 18 builds por dia.

Fontes

--

--

Douglas Fernandes
bawilabs

Geek apaixonado por café e pelo tricolor do Morumbi