HelmDeploy@0 does not play well with values that have spaces

[giggio]

Required Information

Type: Bug

Enter Task Name: HelmDeploy@0

Environment

• Server - Azure Pipelines

  • If using Azure Pipelines, provide the account name, team project name, build definition name/build number: simp-cloud/SaaS/pipelineId=50/buildId=1788

• Agent - Private:

  • OS of the machine running the agent and the agent version: Ubuntu 18.04, agent 2.160.0

Issue Description

If you have values with spaces that you need to set, it is already very complicated to get this to work with helm, you end up having to use double quotes with single quotes, or escape the string (see this - still open - issue on the Helm repo).

The problem gets worse on Azure DevOps because the Helm task is removing quotes from the arguments.

Task logs

Here is a stripped down, commented and redacted version of the logs. Note that the quotes are being stripped, even though they appear on the arguments.

##[debug]found: '/agent/_works/c47a627d22eb/_tool/helm/2.14.3/x64/linux-amd64/helm'
##[debug]/(stripped))/helm arg: upgrade
(stripped for brevity)
##[debug]/(stripped))/helm arg: '--set=foo.ConnectionStrings__DefaultConnection="***"'
                                                                                ^^^^^
                                                                                quotes
##[debug]exec tool: /agent/_works/c47a627d22eb/_tool/helm/2.14.3/x64/linux-amd64/helm
##[debug]arguments:
(stripped for brevity)
##[debug]   '--set=foo.ConnectionStrings__DefaultConnection=***'

                                                            ^^^
                                                          no quotes

I suggest you battle test this scenario, as I guess it is a common one. Also the connection string is a Sql Connection string, and the spaces come from Initial Catalog and Connect Timeout.

If you need more info I'm glad to help. Right now I'm moving to a bash script to work around this.

[vithati]

@giggio, This is logging issue, Are you seeing any issue during execution?

[giggio]

Yes, it is different to run helm install with the variable and the HelmDeploy@0 task. You get different behaviors.

This is how I'm running it now:

          - script: |
              cat <<EOF | helm upgrade --debug --namespace ns --install --version=0.0.$(Build.BuildId) --debug releaseName $(registryName)/chartName --wait --values -
              example:
                secrets:
                  secretName:
                    Bus__AzureServiceBus__ConnectionString: '$(sbConnectionString)'
              EOF

[vithati]

@giggio , We have tried with variable value having spaces but we didn't see any issues. Can you give more example what scenarios HelmDeploy@0 task not working? We will try to repro the issue.

[christianteh]

if we set the connection string as variable in release pipeline, and add it as argument in helm upgrade, for example --set a.dbconnectionstring = $(dbcon), the task would fail

[vithati]

@christianteh , if you have spaces in variable value. you need to put quotes around variable. --set a.dbconnectionstring="$(dbcon)".

[giggio]

That build is still on my system, the error says:

##[error]Error: This command needs 2 arguments: release name, chart path

As you can see from the task logs, I had put quotes on the values:

##[debug]/(stripped))/helm arg: '--set=foo.ConnectionStrings__DefaultConnection="***"'

I tried different combinations, but could not get it to work. The build and build definition id are on the first comment, can you check the logs?

[christianteh]

@vithati yes i did that however as giggio mentioned, it's been stripped out by the task

this is what i add in my argument, --set api.DBConnectionString = "$(DBConnectionString)"

i have to work around this issue like giggio, except that i dont use bash script i created the values file during build to be used in the release process

[shigupt202]

To test this scenario, I executed a simple Helm upgrade command with arguments as: --set=my-key="$(my-val)" I've set the variable my-val as my value. There is a space in the variable, but the build is still successful. Although the quotes are stripped in the log, but that doesn't affect the execution of the command.

[shigupt202]

Attaching the task that I've used: The highlighted variable contains space.

[giggio]

I'm using Yaml. Are they different?

[christianteh]

yeah you are right, my apologies.

The connection string that i used has got , (comma) in it. that explains the issue that i am having. Should have tried it with simple string with space first

[shigupt202]

@giggio There's no difference between Yaml and designer view. I tried the same thing with Yaml, and the build still succeeds. Please make sure that you are not using any variables with special characters (other than spaces), without escaping them.

[giggio]

I didn't, the variable is the same, I only switched from the helm task to the script task, and it worked, and that shows me that the problem exists. I'm fine using scripts, so to me that is ok, I reported to let Microsoft aware. The problem will happen to other users, for sure.

[saeedmaghdam]

I know the last response is for Nov 2019, but I still have the same problem.

I have the following overrides:

      overrideValues: |
        configmap.mongoSettings.connectionString="$(MongoSettings-ConnectionString)"

And $(MongoSettings-ConnectionString)" has special characters like dot (.), comma (,), and semi-colon (;) in it. When I run the pipeline, it complains with the following exception message:

##[error]Error: failed parsing --set data: key "nl" has no value (cannot end with ,)

I used quotation (') and double-quotation (") around the $(MongoSettings-ConnectionString) in overrides, but none helped me.

Am I missing something?