See also general config file documentation.

    [[gitlab.basic.runner]]
# A Gitlab runner token provided during registration.
# See https://doc.cedarci.com/config/gitlab-runner.
token = ""

# --------------------------------------------------------------------
# Optional: defaults inlined.

# CPU core count: 2, 4, 8, ...
# For CPU values see https://doc.cedarci.com/financial/pricing/.
cpu = 4

# Limit the number of jobs that can run at the same time.
# For cost buckets see https://doc.cedarci.com/financial/pricing/#passive.
concurrent = 45

# URL of Gitlab instance to poll for jobs.
url = "https://gitlab.com"

# Default job image if not specified in .gitlab-ci.yml definition.
image = "ruby:3.1"

# The maximum number of builds for which a machine may be used.
# Reusing machines benefits from warm caches and git repositories, and reduces
# the boot time overhead per job.
build_count_max = 20

# The number of machines to preemptively boot and keep idle.
idle_count = 0

# The length of time, in seconds, to keep a machine idle after running a job.
# Only relevant if build_count_max > 1, otherwise terminated immediately.
# Most effective for pipelines that run successive jobs in stages to minimize boot
# overhead to the start of a pipeline while avoiding a higher idle_count.
idle_time = 15

# Restrict the images allowed for jobs.
# By default, any image is allowed which is equivalent to ["*/*:*"]. For
# example, restrict to a single registry with: ["registry.example.com/*:*"].
allowed_images = []

# Restrict the images allowed for services.
# Uses the same default and format as `allowed_images`.
allowed_services = []

# Time based auto-scaling overrides to: idle_count and idle_time.
# The default is effectively an empty array, but expanded for the purpose of documentation.
# Periods and timezone are required along with one of the overrides.
[[gitlab.basic.runner.auto_scale]]
# List of crontab style periods during which to apply overrides.
# * * * * * * *
# | | | | | | |
# | | | | | | year (1970 - 2099)
# | | | | | day of the week (0–6) (Sunday to Saturday)
# | | | | month (1–12)
# | | | day of the month (1–31)
# | | hour (0–23)
# | minute (0–59)
# second (0-59)
# To scale-up during the workday (8am to 6pm Monday through Friday) a period of
# ["* * 8-18 * * MON-FRI *"] should be used.
periods = []

# The timezone in which to evaluate the periods.
# https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
timezone = ""

# One or more of the following values to override. See above for documentation.
idle_count = 0
idle_time = 0

    Recommendation 

    To ensure the most responsive CI the follow are recommended.

    • Utilize machines for more jobs by setting build_count_max to a value like 50. The downside to larger values is mostly disk exhaustion, but a higher value generally means more machines building up during high use periods which ensures higher throughput and higher reliability by reusing cache, container image, and git repository.

    • Tune the idle_time to exceed the delay between pipeline stages or repository workflows. For example, if merge trains are used then a merge request will run a pipeline in the train and one after merging. If the train pipeline takes 10 minutes an idle_time of 15 * 60 would ensure machines from the first run are around to service the merged pipeline without delay.

    • Configure auto_scale to cover primary work hours with an idle_count equivalent to the maximum number of jobs in a pipeline stage (thus started at once) multiplied by the number of pipelines started at the same time. This value will vary greatly based on the size of company and use of CI.