## Problem Jobs sometimes time out during the `get_sources` stage, such as when the `git clone` operation to fetch the repository from the remote hangs. In these situations, the timeout that is reached is actually the job-level timeout, which may be long (e.g., 2 hours) to accommodate the main part of the job. If the `get_sources` stage is stuck, such as due to a hung network transfer, there is no mechanism to terminate the job early (it must wait the full job timeout), which wastes a concurrency slot and delays feedback. ## Proposed Solution Introduce a configurable timeout for the `get_sources` stage, allowing jobs to fail fast. ## Expected Behaviour 1. A `get_sources_timeout` config option is supported in the runner config (`config.toml`) as a `*time.Duration` 2. The `get_sources_timeout` defaults to the job timeout (to ensure backward compatibility). 3. If `get_sources_timeout` is configured to be a value greater than the job timeout, it is clamped to the job timeout and a warning is logged to indicate this Similar work has been done for https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/26583+. This should be used as a reference for the implementation (config field, accessor method, enforcement). ## Extensions 1. A job-level CI variable override (like `RUNNER_SCRIPT_TIMEOUT`) is a natural follow-up to this, allowing for the runner-level timeout to be overridden with a shorter value if appropriate