DevOps / GitLab CI Basics Interview Questions
What are common reasons a GitLab CI pipeline fails and how do you troubleshoot them?
When a pipeline fails, GitLab provides job logs, exit codes, and visual indicators to help diagnose the issue. A systematic approach to troubleshooting resolves most failures quickly.
| Failure | Likely cause | Fix |
|---|---|---|
| Job stuck in 'pending' | No runner available with matching tags | Check runner availability; verify job tags match a runner |
| 'script: command not found' | Tool not installed in the Docker image | Change image to one that includes the tool, or install it in before_script |
| Timeout | Job exceeds project or job timeout | Increase timeout or optimise the slow step |
| Artifact not found | Dependency job failed or wrong path | Check dependency job passed; verify artifact path |
| Permission denied (push) | CI_JOB_TOKEN lacks write access | Enable token access in Settings > CI/CD > Token access |
| Cache not working | Cache key mismatch or runner has no cache storage | Check cache key; verify runner has cache storage configured |
| YAML syntax error | Invalid .gitlab-ci.yml | Use CI Lint tool to validate before committing |
# Debugging tips: # 1. Check the full job log - error is usually at the bottom # Build > Pipelines > Click the failed job > View log # 2. Add debug output to the script: job-debug: script: - env # print all environment variables - ls -la # show workspace contents - which node && node -v # verify tools are installed - cat /etc/os-release # check OS in the Docker image # 3. Enable CI/CD debug logging: variables: CI_DEBUG_TRACE: "true" # very verbose - shows all shell commands # 4. Re-run a single failed job: # Click the failed job > Retry # Or retry from the pipeline view # 5. Use CI Lint to validate YAML before pushing: # Build > Pipelines > CI Lint
Most common beginner mistake: setting GIT_STRATEGY: none in a job that actually needs repository code, or forgetting that artifacts from a failed job are not available by default (add artifacts: when: on_failure to capture debug files from failing builds).
A GitLab CI job is stuck in 'pending' for a long time. What is the most likely cause?
What does setting CI_DEBUG_TRACE: 'true' do in a GitLab CI job?
More Related questions...
