I have come across a very strange situation while deploying a Java jar
using Azure DevOps Pipelines
I am using task: Bash@3
to execute a shell
command 'java -jar my-app.jar'
I have 1 secret
called db-password
from Azure KeyVault
as a variable
whose value is say 123"xk'cv
I need to set this as a Spring Boot Application property
in order to access the datasource
in my application.
The yml
script to run java -jar command is as follows:
steps:
- task: Bash@3
displayName: 'Deploy jar'
inputs:
targetType: 'inline'
script: |
cd build/libs
java -jar -Dspring.datasource.password=$(db-password) my-app.jar
Due to the presence of one double quote "
or single quote '
in the secret
value, the Azure Devops pipeline
is failing with the following error:
/myagent/_work/_temp/xxxx.sh: line 2: unexpected EOF while looking for matching `''
/myagent/_work/_temp/xxxx.sh: line 3: syntax error: unexpected end of file
I need a way to:
Escape the double quote or single quote from the secret
value and execute the above pipeline.
Changing the secret value is not an option as it is a production database and multiple teams are accessing it.
The Question might not be related to Azure Pipeline, it may be a simple bash or Spring boot hack.
Any help is appreciated, thanks in advance.
2
Answers
I put this as an answer for formatting purposes, try this :
According to Microsoft’s docs on using secret variables, "You’ll need to map secret variable as environment variables to reference them in YAML pipelines."
I’m not entirely clear on Azure’s YAML structure, but AIUI that’ll mean adding something like this at some level under
steps
:And using it like this in the bash script:
This way the password isn’t actually substituted into the script’s text; instead, bash will see
"$password"
and expand it to the environment variable’s value. Since it’s in double-quotes, bash doesn’t do any parsing at all on the variable’s value, so any quotes, spaces, wildcards, etc will not cause parsing problems.BTW, many sources recommend using all-caps variable names for environment variables, but lower- and mixed-case names are actually safer because of all of the all-caps names that have special meanings. If you don’t want any of those special meanings, use lowercase to avoid accidental conflicts with any of those special-meaning variables.