We can change this behavior by changing the cache policy. Avoiding useless work using cache policyīy default, each time a job with cache tries to pull the cache specified in its definition in gitlab-ci.yaml, then it executes the commands in the script and finally, it pushes the new changes to the files under cache:paths to the cache storage server again. The gain can be more important if you are self-hosting Gitlab on a machine with slow internet speed. In our case the pipeline with cached node_modules are faster by more than 2 mins than the one without. The new version will look something like this (The unchanged parts are omitted for brevity). We will add the cache key to all yarn-related jobs.
This way each time yarn.lock changes, the cache gets invalidated and rebuilt from scratch. To do so we'll need to cache the node_modules folder and preferably use yarn.lock file as a cache key. For this reason it should be done at most once per pipeline execution. This operation is redundant and so costly in time.
CRAZY OLD GIT DEFINITION INSTALL
In the previous gitlab-ci.yaml file we can see that we need to install yarn dependencies aka node_modules each time we need to execute a yarn command. The Gitlab documentation devoted an entire page to caching with a good amount of details about all the caching features and their use-cases. docker build -t $/gprg:latestĬaching is one of the most useful techniques we can use to speed-up gitlab CI jobs. docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY Gitlab CI/CD pipelineĪn example gitlab-ci.yml file will look something like this: stages: Our pipeline will install our node dependencies, test the code, build it and package it as a docker image. For our case we will work on the most basic pipeline for a node project. In Gitlab CI/CD, a pipeline is simply a collection of jobs. The files are even stored in an object storage service like S3 or MinIO or in the container filesystem itself. In case we've specified artifacts or caches in our CI files, the job carries two more tasks out, for pulling and(/or) pushing some files as caches or artifacts. Then the runner starts by preparing the execution environment: in the docker executor case, it pulls the image specified in gitlab-ci.yml and creates a container from the same image.īy the time the container is up, the runner clones the git repo into it and runs our script from. Once the runner is available, the job gets picked. When a job is created, it goes into the pending state, until a runner is available. The job Anatomyīefore diving deeper into pipeline optimization, let's take a closer look on how Gitlab jobs work and what are their execution phases. In this article, we will create a GitLab CI/CD pipeline for a React project and walk through the optimization process exploring the most common problems, their solutions, and the trade-offs we can make to have faster pipelines and happier development teams. However not doing it right can have an opposite effect on the delivery process and sometimes on the team productivity and happiness.
CRAZY OLD GIT DEFINITION SOFTWARE
CI/CD (Continuous Integration/Continuous Delivery) is one of the most useful techniques to reduce friction between dev and ops teams and improve software delivery time.
0 kommentar(er)
