DevOps / Gitlab Interview questions
Explain the execution flow of a GitLab CI/CD pipeline from commit to deployment?
When a developer pushes a commit, GitLab checks the repository for a .gitlab-ci.yml file and, if found, creates a pipeline made up of the stages and jobs defined there. GitLab then looks for an available Runner tagged to accept each job.
sequenceDiagram
participant Dev as Developer
participant GL as GitLab Server
participant Runner as GitLab Runner
participant Reg as Container Registry
participant Env as Deploy Target
Dev->>GL: git push (commit)
GL->>GL: Parse .gitlab-ci.yml, create pipeline
GL->>Runner: Assign build job
Runner->>Runner: Checkout code, run script
Runner->>Reg: Push built image
Runner-->>GL: Report job status
GL->>Runner: Assign test job (next stage)
Runner-->>GL: Report test results
GL->>Runner: Assign deploy job
Runner->>Env: Deploy image/artifact
Runner-->>GL: Report deployment status
GL-->>Dev: Update pipeline status on MR/commit
Each stage only starts once every job in the previous stage succeeds, unless allow_failure or a DAG-style needs relationship changes that ordering. Artifacts produced by earlier jobs, like a compiled binary or built image, can be passed forward to later jobs (such as deploy) without rebuilding them. The final status, pass or fail, is reported back onto the commit and any associated merge request, which is what blocks or allows a merge depending on the project's rules.
What typically triggers a GitLab CI/CD pipeline to start?
By default, a later stage starts only after:
More Related questions...
