GitLab Runner and Rails API: Job Priority Logic During Concurrent Polling
0 reputation · 18 May 2023, 15:18 UTC
GitLab Runners utilize a polling mechanism to request available jobs from the GitLab Rails API. While concurrency is manageable via the concurrent setting in config.toml and the global instance limits, the interaction between multiple runners and the server-side job queue introduces complexity during high-volume bursts.
When numerous runners with overlapping tags poll the API simultaneously, the server must determine which runner receives which pending job. There is uncertainty regarding the internal priority queuing logic when runners with different tag sets compete for the same pool of pending jobs under extreme concurrency.
- Does the GitLab Rails API prioritize runners with more specific tag matches over those with broader matches during a single polling cycle?
- How is the job distribution handled when multiple runners request work at the exact same millisecond?