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

1. Deploy a new runner via Helm and define a request_concurrency value like so within your values.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.