I'm using maven and have a list of system properties -DA=alpha, -DB=beta -DS=random_stuff that I want to pass down to unit tests when maven runs, and which cannot go into the pom files.
Surefire and Failsafe plugins both basically say you can pass values down to tests by passing them via the -DargLine system property.
Usually it's defined in the pom.xml, e.g.
<argLine>-DA=alpha -DB=beta -DS=random_stuff</argLine>
But I have also seen examples where -DargLine=... was passed in from the command line.
I believe that I need to put quotes around the system properties I want to pass in via argLine, as they are space separated:
-DargLine="-DA=alpha -DB=beta -DS=random_stuff"
And now I want to pass them in via the MAVEN_OPTS environment variable (which also "carries" other system properties, not just argLine). What I have so far is:
MAVEN_OPTS="-Dxyz=abc ... -DargLine=\"-DA=alpha -DB=beta -DS=random_stuff\""
In other words, I escaped argLine's quotes. Unfortunately, the end quote is now treated as part of -DS's value, i.e. S now gets replaced by random_stuff" - not what I want.
How can I do what I want to do, i.e. make sure A, B, and S are passed in as part of argLine, and pass argLine through as part of MAVEN_OPTS?
P.S.: I also tired inner single quotes (equally unusable result: some_stuff') and unescaped inner double quotes (MAVEN_OPTS=" ... -DargLine="-DA=alpha ..."", resulting in errors when trying to source .bash_profile), both unsuccessfully...
Related
I have a situation where I have an environment variable with space character inside. Some tools do not like quoting the value of the variable, as they will treat the quote as part of the variable.
This is set in a .env file.
PIP_EXTRA_INDEX_URL="https://token#repo https://token#repo"
When I include and export this .env file in a Makefile, I get this warning.
WARNING: Location '"https://token#repo' is ignored:
it is either a non-existing path or lacks a specific scheme.
But I have seen this behavior as initially mentioned also with other tools. Is there a way to handle this?
In the Makefile, I include it like below.
include .env
export
build:
docker build --build-arg PIP_EXTRA_INDEX_URL -t myimage .
Makefiles are not shell scripts and it is not possible to use the same syntax to define variables in both the shell and in make, except in very limited situations.
In the shell, you can have multiple assignments on the same line or even run programs on the same line. So, if your assignment has whitespace in it you have to quote it as you've done here.
In make, the syntax of an assignment is that all text after the assignment (and leading whitespace) becomes the value of the variable and there is no quoting needed; any quotes that are seen are kept as part of the variable value.
So, in the shell this assignment:
PIP_EXTRA_INDEX_URL='https://token#repo https://token#repo'
sets the shell variable PIP_EXTRA_INDEX_URL to the value https://token#repo https://token#repo ... note the quotes are stripped from the value by the shell.
In make this assignment:
PIP_EXTRA_INDEX_URL='https://token#repo https://token#repo'
sets the shell variable PIP_EXTRA_INDEX_URL to the value 'https://token#repo https://token#repo' ... note the quotes are not stripped from the value by make.
So if you use this value in a recipe like this:
do something "$(PIP_EXTRA_INDEX_URL)"
then make will expand that variable and you'll get:
do something "'https://token#repo https://token#repo'"
(including quotes) and that's your problem.
It works like this.
build:
docker build --build-arg PIP_EXTRA_INDEX_URL=$(PIP_EXTRA_INDEX_URL) -t myimage .
I'm trying to get a simple build bash script to work and can't get the date as an argument. What am I missing here? Thanks.
#!/bin/bash
buildDate=$(date)
go build -ldflags='-X main.buildTimestamp=$buildDate' main.go
Output: Build: $buildDate
To quote the documentation on a POSIX-compatible shell:
2.2.2 Single-Quotes
Enclosing characters in single-quotes ( '' ) shall preserve the literal value of each character within the single-quotes. A single-quote cannot occur within single-quotes.
So, in your particular case, bash breaks the go build … command into words and performs string substitution before actually executing the command.
As per string substitution rules, the text enclosed with single quotes is taken literally, so after the expansion the shell looks up the go command and executes it pasing it the tree resulting arguments, which are, in order: build, -ldflags=-X main.buildTimestamp=$buildDate and main.go.
Since the Go toolchain does not invoke shell anywhere in its course of work, the literal text $buildDate gets passed unmodified to the compiler.
If the format of your build date does not include whitespace, the easiest fix is to just replace the single quotes with double quotes.
If you need to embed spaces in there, it gets a little bit more tricky but not too much — to cite the output of go build help:
The -asmflags, -gccgoflags, -gcflags, and -ldflags flags
accept a space-separated list of arguments to pass
to an underlying tool during the build.
To embed spaces in an element in the list, surround
it with either single or double quotes.
<…>
In other words, the command-line argument parser considers pairs of "s and 's to implement argument grouping, and in your case you could do
go build -ldflags="-X main.buildTimestamp='$buildDate'" main.go
so that the shell strips out the outer double quotes and substitutes $buildDate for its value — as per the rules of string substitution for the case of double quotes.
Hence, if your build date format includes spaces, like in, say, Tue, 12 May 2020 20:53:16 +0300, the go command would receive the following three arguments, in order: build, -ldflags=-X main.buildTimestamp='Tue, 12 May 2020 20:53:16 +0300' and main.go, and would take care of those single quotes by itself.
To pass parameters containing a list to a Maven build from command line, we can use the "-D" option and pass the values as a comma separated. Maven internally converts this into List, and uses down the line. This has been answered in this question.
However, if the parameters I try to pass has comma (or any other special character like brackets) in them, how should I pass them?
Eg: I need to pass the following 3 strings from command line to Maven build.
In the pom it can be done as:
<argsList>
<arg>Hello</arg>
<arg>Hello, Hi</arg>
<arg>Hello (Rohan, Ryan), Hi!</arg>
</argsList>
How do I pass these with the "-D" option? I tried encasing inside single...
mvn compile -Dmyproperty='Hello','Hello, Hi', 'Hello (Rohan, Ryan), Hi!'
and double quotes,
mvn compile -Dmyproperty="Hello","Hello, Hi", "Hello (Rohan, Ryan), Hi!"
but both fail.
Is it possible to concatenate a string to call a Bamboo variable.
Using a script task in Bamboo, I want to generalize the following:
python my.py moon ${bamboo.mynamespace.moon}
to
SET planet=MOON
python my.py %planet% ${bamboo.mynamespace.%planet%}
But doing it like the second example above results in my python script receiving
${bamboo.mynamespace.%planet%}
as a string and not the value of
${bamboo.mynamespace.moon}
I know... moon is not a planet
I don't think it's going to be possible in the way how you're using it. Because once you use ${bamboo.variableName} Bamboo tries to resolve the variable and substitute it with a variable value. Since there's no variable%planet% Bamboo can't reference it.
But I think you could reorganise your solution a bit and make use environment variables (all Bamboo variables are passed to process as environment variables). So e.g. if Bamboo variable's name is variable.name you're allowed to reference to it via ${bamboo_variable_name} (bamboo prefix + all dots are replaced with underscore)
Then I can imagine you could get variable which interests you via print os.environ['bamboo_mynamespace_' + 'planet'] (more info on env variables in python here)
This is a system Octopus Deploy Variable:
#{Octopus.Action[Deploy To Server].Output.Package.InstallationDirectoryPath}
The text "Deploy to Server" is the name of the step in my project that deploys the Nuget Package to the server. This variable gives the install location of the NugetPackage.
I am wondering if I can make this more generic:
#{Octopus.Action[#{DeploymentStep}].Output.Package.InstallationDirectoryPath}
#{DeploymentStep} is itself a variable with the value of "Deploy to Server"?
I tried this and it not did do the substitution when it tried to run. But I am hoping there is a different syntax for variable in variable substitution.
(I want to do this so I can make this the default value for a Step Template.)
It can be done; but you need to use slightly different syntax!
Variable substitution syntax: http://docs.octopusdeploy.com/display/OD/Variable+Substitution+Syntax
$deploymentStep = "#{DeploymentStep}"
$installationDirectory = $OctopusParameters["Octopus.Action[$deploymentStep].Output.Package.InstallationDirectoryPath"]
Have just had the same issue, but with a few tests I got it working in a 1 liner.
You need to encapsulate the inner variable in brackets with a dollar, and you need to change the double quotes within the variables to single quotes so it doesn't complain about the miss match of quotes. Double quotes on the outside and single quotes in the in.
The example below gets a step name with an octopus variable and also a the machine name it ran on variable to produce the result:
$OctopusParameters["Octopus.Action[$($OctopusParameters['Octopus.Step.Name'])].Output[$($OctopusParameters['Octopus.Machine.Name'])].MyVarFromMachineFromStep"]