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 thanrequest-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
containingconcurrent = 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 containsconcurrent = 4
Test interactive mode:
- have an existing configuration
~/.gitlab-runner/config.toml
containingconcurrent = 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 withrequest_concurrency = 4
- notice how
~/.gitlab-runner/config.toml
now containsconcurrent = 4
What are the relevant issue numbers?
Edited by Lee Tickett