Mastering GitLab CI Runners: Timeout Configurations You Need
Configuring runners in GitLab CI is essential for maintaining control over job execution times. Without proper timeout settings, you risk having long-running jobs consume resources and delay your entire CI/CD pipeline. By leveraging timeout configurations, you can ensure that jobs complete within a reasonable timeframe, enhancing overall efficiency and reliability.
The key parameters you need to understand are maximum_timeout, RUNNER_SCRIPT_TIMEOUT, and RUNNER_AFTER_SCRIPT_TIMEOUT. The maximum_timeout parameter sets a ceiling on job timeouts for each runner. If this is shorter than the project-defined timeout, the job will adhere to the runner's limit. For example, if maximum_timeout is set to 24 hours but the project timeout is 2 hours, the job will time out after 2 hours. The RUNNER_SCRIPT_TIMEOUT variable allows you to specify a timeout for the job script itself, while RUNNER_AFTER_SCRIPT_TIMEOUT sets a timeout for the after_script phase, overriding the default of 5 minutes. This granularity helps you manage resource allocation effectively.
In production, be aware of the security implications of using instance runners, which are accessible to all groups and projects. If a registration token is compromised, reset it immediately to prevent unauthorized runner registrations. Also, remember that these timeout features were introduced in GitLab Runner 16.4 and GitLab 15.5, so ensure your versions are up to date to leverage these capabilities fully.
Key takeaways
- →Set `maximum_timeout` to prevent long-running jobs from monopolizing runner resources.
- →Use `RUNNER_SCRIPT_TIMEOUT` to limit how long your job scripts can run.
- →Override the default `after_script` timeout with `RUNNER_AFTER_SCRIPT_TIMEOUT` for better control.
- →Be cautious with instance runners due to their broader access and security risks.
- →Reset registration tokens if they are exposed to avoid unauthorized access.
Why it matters
Properly configuring runner timeouts can significantly reduce resource waste and improve CI/CD pipeline efficiency, leading to faster feedback cycles and more reliable deployments.
Code examples
job-with-script-timeouts:variables:RUNNER_SCRIPT_TIMEOUT:15mRUNNER_AFTER_SCRIPT_TIMEOUT:10mscript:-"I am allowed to run for min(15m, remaining job timeout)."after_script:-"I am allowed to run for min(10m, remaining job timeout)."job-artifact-upload-on-timeout:timeout:1h# set job timeout to 1 hourvariables:RUNNER_SCRIPT_TIMEOUT:50m# only allow script to run for 50 minutesscript:-long-running-process > output.txt# will be terminated after 50mjob-with-script-timeouts:timeout:5mvariables:RUNNER_SCRIPT_TIMEOUT:1mRUNNER_AFTER_SCRIPT_TIMEOUT:1mscript:-echo "Starting build..."-sleep 120# Wait 2 minutes to trigger timeout. Script aborts after 1 minute due to RUNNER_SCRIPT_TIMEOUT.When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsMastering Environments in GitLab CI/CD: Static vs. Dynamic
Understanding environments in GitLab CI/CD is crucial for effective deployment management. You'll learn how to leverage static and dynamic environments to streamline your deployment process and capture environment URLs seamlessly.
Maximizing GitLab CI Pipeline Efficiency: Key Strategies
Pipeline efficiency in GitLab CI is crucial for reducing build times and improving developer productivity. Understanding the critical path and utilizing caching effectively can significantly speed up your workflows. Dive in to learn how to analyze and optimize your CI/CD pipelines.
Mastering GitLab CI/CD YAML: Key Syntax You Need to Know
Get your pipelines running smoothly with a solid grasp of GitLab CI/CD YAML syntax. Understand how global keywords and job configurations can streamline your CI/CD processes. Dive into practical examples to elevate your pipeline management skills.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.