Helm deployed runner ignores request_concurrency
Summary
Defining request_concurrency
value via the new advanced configuration within the values.yaml
file results in the value being ignored and set to the default of 1.
Steps to reproduce
- Deploy a new runner via Helm and define a
request_concurrency
value like so within yourvalues.yaml
file:
config: |
[[runners]]
request_concurrency = 5
What is the current bug behavior?
The user defined value for request_concurrency
is ignored, and the default value of 1 is used.
It looks like we're passing the values defined in the config
section of the values.yaml
via the --template-config
flag here. This flag has the following caveat:
The merging is done only for options that were empty. That is:
- Empty strings.
- Nulls or/non existent entries.
- Zeroes.
Since we define a default value of request_concurrency
within _env_vars.tpl only for the Helm chart, a user defined value within the values.yaml
config key (see example above) will be ignored.
You can confirm this is the cause by downloading the runner helm chart repository locally, and setting the default value to 0 within _env_vars.tpl
. If you then deploy a runner with the local helm chart, a user-defined request_concurrency
value will be applied to the runner.
What is the expected correct behavior?
The user defined value for request_concurrency
is used.
Possible fixes
Not necessarily a fix, but we should remove the DEPRECATED notice from the requestConcurrency
example in the values.yaml file as this is the only way a user can currently change this value.