When using the helm command and overriding values using --set, if the key value contains a comma, the value is halted there. i want to pass a value with comma.
For example -set connString=service_name:8080,password=xxxxx=,abortConnect=False
and in my helm I'm using this connection string.
connString: ""
Cons__cache: "{{ .Values.connString}}"
But service_name:8080 is stored.
You can try this:
--set connString='service_name:8080\,password=xxxxx=\,abortConnect=False'
or
--set connString=service_name:8080\,password=xxxxx=\,abortConnect=False
Link references:
https://helm.sh/docs/intro/using_helm/
https://github.com/helm/helm/issues/1556
Related
I have an Automator workflow which should set the CreationDate of the selected file to a date which I want to enter. Unfortunately my path have spaces. Therefore it doesn'w work.
I've tried several variants like:
SetFile -d \"$1 12:00:00\" "$#2"
SetFile -d \"$1 12:00:00\" \"$#2\"
SetFile -d \"$1 12:00:00\" '$#2'
SetFile -d \"$1 12:00:00\" \'$#2\'
The path is like follows:
/Users/simon/Documents/Steuern/Steuern 2021/Scan_000775.pdf
The shell I use is ZSH with oh-my-zsh installed.
This is the Workflow I have:
Ask for Finder-Object
Get value of variable
Ask for Text input
Set value of variable
Ask for value of variable
execute shell script: "SetFile -d "$1 12:00:00" "$#2""
Can anyone tell me how to write the shellscript to use pathnames with spaces?
That would be very nice. Thank you.
If I'm understanding right, you want:
SetFile -d "$1 12:00:00" "${#:2}"
Explanation: escaping quotes prevents them from acting like quotes (it turns them into normal characters); in this case, you want them to function as quotes, so you shouldn't escape them. Also, "$#2" doesn't get the arguments starting at $2, it gets all of the arguments, and sticks a "2" to the end of the last one. If you want all the arguments except the first, use "${#:2}" instead.
I am trying to use the "az pipelines variable-group variable create ..." command to create a variable which references a different variable. e.g.
az pipelines variable-group variable create --project MyTestProject --
group-id 15 --name ‘ApplicationName’ --value 'TestApp-$(env)'
where the variable “env” is defined in a variable-group within the same project library.
When I run the command above it gives the error:
“Failed to load python executable” “exit /b 1”.
Despite an error being generated the variable is created; in the example above the variable 'ApplicationName' has the value 'TestApp-$(env', the trailing bracket character, ")", is missing and seems to be causing the problem.
The dollar sign, "$", and/or the opening bracket character "(" don't generate any error when used without the closing bracket ")".
I have tried escaping the closing bracket character with backslashes "\" and caret "`" characters but couldn't find any combination that would create the desired variable value, "TestApp-$(env)".
Could someone tell me how to escape the closing bracket so the variable is correctly created within the variable group.
I am running the following versions of az:
azure-cli 2.0.73
command-modules-nspkg 2.0.3
core 2.0.73
nspkg 3.0.4
telemetry 1.0.3
Extensions:
azure-devops 0.12.0
Python (Windows) 3.6.6
Many Thanks,
Gary
I have finally managed to figure out how to escape a variable whose name itself contains a different variable name. By calling the az cli command and wrapping the variable value in double quotes and a single quote, the variable is correctly created in DevOps:
pipelines variable-group variable create --project MyTestProject -- group-id 15 --name ApplicationName' --value '"TestApp-$(env)"'
DevOps-LibraryVariable-screenshot
As a further expansion on this topic I had a need to pass the value as a variable. My source was in a key value pair. In this case I used the following.
$key = $var.Key
$value = '"{0}"' -f $var.Value
az pipelines variable-group variable update --group-id $groupId --org $org --project $project `
--name $key --value $value
It depends on your OS and tools.
For example, in Windows OS, you can get environment variable with %variable_name%. So, the following would be right:
az pipelines variable-group variable create --project keyvault --group-id 1 --name "ApplicationName" --value "TestApp-%java_home%"
However, in PowerShell, you can get environment with "$env:variable_name". So, the following would be right:
az pipelines variable-group variable create --project keyvault --group-id 1 --name "ApplicationName2" --value "TestApp-$($env:java_home)"
Update:
So, in Azure Pipeline, you can use group variables as following:
pool:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
- vstest
variables:
- group: vargroup
steps:
- task: AzureCLI#1
inputs:
azureSubscription: 'CSP Azure (e5b0fcfa-e859-43f3-8d84-5e5fe29f4c68)'
scriptLocation: 'inlineScript'
inlineScript: |
echo the variable var1:%var1%
I have a variable group:
And you can see that: echo the variable var1:%var1% will be echo the variable var1:value1
Is it possible to obtain the Job Description or the Job Parameter Description in run-time or later like the BUILD_ID or JOB_NAME?
I search for plugins or workarounds and nothing.
Thanks.
This would be Tip/workaround
https://<<yourjenkinsdomain>>/job/<<yourjobname>>/configure (will open the configuration of your job)
However
https://<<yourjenkinsdomain>>/job/<<yourjobname>>/config.xml (will give the job configuration in an xml format)
You can download this xml via curl at run time or using jenkins cli and use a grep with -B option to find description per value.
Considering you have copied the with name "config.xml"
cat config.xml | grep -B 1 "description"
Will give you description and build parameter name
Grep command
-B NUM, --before-context=NUM
Print NUM lines of leading context before matching lines.
Places a line containing a group separator (--) between
contiguous groups of matches. With the -o or --only-matching
option, this has no effect and a warning is given.
Sample output :
cat config.xml | grep -B 1 "description"
<actions/>
<description>Job description : Automation </description>
--
<name>branch</name>
<description>mandatory parameter , used for automation</description>
--
Alternative :
jenkins cli has an option to set value
set-build-description Sets the description of a build.
set-build-parameter Update/set the build parameter of the current build in progress. [deprecated]
you can write a small script and get the values into variables and use them
I have a supervisord file where like this
[program:decrypt]
command=export KEYTOKEN=$(aws kms decrypt --ciphertext-blob fileb://<(echo %(ENV_TOKENENC)s | base64 -d) --output text --query Plaintext --region %(ENV_REGION)s | base64 -d )
I am passing the environment ENV_TOKENENC,ENV_REGION to the container and I can echo those variables and confirm that the docker container is getting them, also the command to decrypt kms value also works.But when I put the kms decrypt command in supervised file it throws error saying ('ENV_REGION')&('ENV_CONSULTOKENENC') which cannot be expanded.
Am I putting the right value in supervisord file?
Setting an environment variable is easy, if you're setting it to a constant value:
[program:decrypt]
command=/usr/bin/env foo=bar baz=qux /path/to/something ...
or, with less overhead:
environment=foo="bar",baz="qux"
command=/path/to/something ...
However, dynamically generating that variable's value requires a shell:
[program:decrypt]
command=/bin/sh -c 'foo=$(generate-bar) /path/to/something'
Note that export is not actually needed here, as var=value something as part of a single command exports var having value value during the execution of something.
I use Jenkins ver. 1.522 and I want to pass a long string with spaces and quotes as a parameter in the parameterized build section. The job only runs a python script.
My problem is that I can't find a way to escape my string so that jenkins passes it correctly to the script.
Assuming...
string: fixVersion in ("foo") AND issuetype in (Bug, Improvement) AND resolution = Fixed ORDER BY resolution ASC, assignee ASC, key DESC
variable name: bar
script name: coco.py
When I run the script in the terminal, everything is fine: python coco.py --option 'fixVersion in ("foo") AND issuetype in (Bug, Improvement) AND resolution = Fixed ORDER BY resolution ASC, assignee ASC, key DESC'
When I run the same script with jenkins using the parametrized build and try to escape the variable so it end up taken as one parameter by the py script it is oddly espacped by jenkins.
In my jenkins job I call the script: python coco.py --option \'${BAR}\'
and it ends up as:
python coco.py --option '"fixVersion' in '('\''foo'\'')' AND issuetype in '(Bug,' 'Improvement)' in '(Production,' 'Stage)' AND resolution = Fixed ORDER BY resolution ASC, assignee ASC, key 'DESC"'
I also tried \"${BAR}\", \"$BAR\",\'$BAR\'
What it the right way do acheive it?
Try
python coco.py --option "${BAR}"
Alternatively, if you need the single quotes surrounding everything
python coco.py --option \'"${BAR}"\'
In the cases you listed, bash will treat the spaces as delimiters. Putting the double quotes around a variable will preserve the whitespace in a string. Example
aString='foo bar'
for x in $aString; do echo $x; done
# foo
# bar
for x in "$aString"; do echo $x; done
# foo bar
I am using Jenkins v1.606 and ran into this same issue!
The issue that I saw passing user defined string params containing spaces into an execution shell would not properly format the string (only with a parameter that had 1 or more spaces). What you have to watch out for is reviewing the 'output' log. Jenkins will not properly display the string param value within the log.
Example (correct format for containing spaces):
docker exec -i container-base /bin/bash -c "cd /container/path/to/code/ && ./gradlew test_xml -P DISPLAY_NAME='${DISPLAY_NAME}' -P USERNAME='${USERNAME}' -P SERVER_NAME='${SERVER_NAME}'"
Jenkins Output of string (notice the string values format):
+ docker exec -i container-base /bin/bash -c 'cd /container/path/to/code/ && ./gradlew test_xml -P DISPLAY_NAME='\''VM10 USER D33PZ3R0'\'' -P USERNAME='\''d33pz3r0#stackoverflow.com'\'' -P SERVER_NAME='\''stackoverflow.com'\'''
Conclusion:
In my example, the literal command was encapsulated with <">, followed by surrounding the parameters with <'> to escape the literal cmd string and control the Jenkins string syntax. Remember not to just watch your Jenkins output log as it lead me wrong for an entire day while I fought with this! This should be the same for your issue as well, you do not need to escape with \' or other escape characters. Hope this helps!!