DevOps / GitLab CI Basics Interview Questions
What is the 'retry' keyword and how do you handle flaky tests in GitLab CI?
The retry keyword automatically reruns a job when it fails, up to the specified number of times. This is useful for handling transient failures - network timeouts, flaky tests, or race conditions - without manual intervention.
# Simple retry: retry up to 2 times on any failure flaky-test: script: - run-tests.sh retry: 2 # total: 3 attempts (1 original + 2 retries) # Retry only on specific failure types: network-test: script: - curl https://api.example.com/data retry: max: 2 when: - runner_system_failure # runner itself crashed - stuck_or_timeout_failure # job timed out - api_failure # GitLab API error during job # NOT for script failures (that would mask real test failures) # All retry "when" values: # always, unknown_failure, script_failure, api_failure, # runner_system_failure, missing_dependency_failure, # stuck_or_timeout_failure, scheduler_failure, data_integrity_failure
| Value | Triggers retry when |
|---|---|
| always | Any failure - use with caution |
| runner_system_failure | The runner system failed (not script failure) |
| stuck_or_timeout_failure | Job timed out or got stuck |
| api_failure | GitLab API error during job execution |
| script_failure | The script returned non-zero exit code |
Best practice: avoid retry: always or retrying on script_failure - these can hide real failures. Only retry on infrastructure failures (runner_system_failure, stuck_or_timeout_failure) where the failure is clearly not the code's fault.
What does 'retry: 2' in a GitLab CI job mean?
Why is it generally bad practice to set 'retry: when: script_failure'?
More Related questions...
