Skip to content

Draft: Query user for runner request concurrency when registering a new runner

What does this MR do?

Currently, we can pass the --request-concurrency command line argument in when registering runners. However, we do not prompt interactively for it, or consider the current concurrent setting when parsing it.

This MR:

  • add an interactive prompt for request-concurrency
  • automatically increases concurrent if lower than request-concurrency

Why was this MR needed?

Users request more abilities to configure concurrency settings in non-interactive ways via CLI arguments. This is relevant when deploying runners programmatically.

What's the best way to test this MR?

Test non-interactive mode:

  • have an existing configuration ~/.gitlab-runner/config.toml containing concurrent = 2
  • run gitlab-runner register -n -u https://gitlab.com/ -r <token> --executor shell --request-concurrency 4
  • notice how ~/.gitlab-runner/config.toml now also contains concurrent = 4

Test interactive mode:

  • have an existing configuration ~/.gitlab-runner/config.toml containing concurrent = 2 and no registered runners
  • register a new runner interactively by running gitlab-runner register
  • notice the new prompt Maximum concurrency for job requests (default: 1)
  • enter 4 for this value
  • notice that ~/.gitlab-runner/config.toml now contains a new runner definition with request_concurrency = 4
  • notice how ~/.gitlab-runner/config.toml now contains concurrent = 4

What are the relevant issue numbers?

Edited by Lee Tickett

Merge request reports