GitLab Architecture

What triggers a GitLab CI/CD pipeline execution?

• Any change made to the Git repository (new file, modification, etc.)

• Reaching a pre-defined code coverage threshold

• A change made to the .gitlab-ci.yml file.

In the GitLab CI/CD architecture, what is the primary role of the GitLab Server?

• to execute the individual jobs within a pipeline

• to store the source code of the project

• to manage pipelines and their associated jobs

• to communicate with external APIs

What is a GitLab Runner, in simplified terms?

• A type of DB that stores pipeline logs

• A program that executes the individual jobs within a pipeline

• A user interface for managing CI/CD pipelines

• A type of cloud server that hosts the GitLab application.

What is the Docker executed for in the pipeline?

• To run Docker images that will be used for building, testing, and deploying the application

• To manage the GitLab Server's resources

• To encrypt sensitive data within the pipeline

• To schedule pipeline jobs based on time

What happens after a GitLab Runner completes a job successfully?

• The Runner immediately shuts down

• The GitLab Runner reports the job's results to the GitLab Server and then deallocates the resources (like the Docker Container)

• The GitLab Runner saves all files to a local disk

• The Gitlab Runner commits all files to the Git repository

Where are the job artifacts (like todo.app) stored after a successful job completion?

• In a temporary directory that's automatically deleted after the job finishes

• Directly within the Git repository alongside the source code

• In the GitLab CI/CD artifact storage, accessible through the GitLab interface and GitLab API

• On the local machine of the GitLab Runner that executed the job.