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)
Related
Duplicate of https://unix.stackexchange.com/questions/159253/decoding-url-encoding-percent-encoding, but SO does not understand url from different stack.
Inside a docker container, I use environment variables (that I do not manage initialy, so I cannot act on them) inside a bash script.
One of the environement variable has one hexa character, but the rest of the string is OK.
Original string is: toto#t.
It is recuperated as toto%40t in the script with the following command:
echo "$VAR"
Note the # that is transformed into %40
With "minimal Ubuntu 20" (Installation of additionnal tools is possible, but I want to avoid it), pure bash if possible, how can I format the variable to get the original format ?
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...
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"]
I am using a switcher that exports environmental variables based upon which machine is being used. One of the variables that gets exported is ems_1 .
Now, in my start.bash script, I am trying to assign a variable called provider with the value ems_1 has.
export provider = ems_1
Doesn't work . Any suggestions ?
export provider=$ems_1
You need to reference variables using the $ sign.
variable=value
cannot have spaces in-between.
I'm trying to lazily evaluate configuration option. I want to issue a Make error only if the variable is actually used (substituted).
Consider the following Makefile:
VAR = $(error "E")
NFS_DIR = NFS_DIR is $(VAR)
T = $(NFS_DIR) is 1
all:
echo Test
If I run it with my environment (which has /srv/nfs value), the output is following:
➜ ~ make
echo Test
Makefile:3: *** "E". Stop.
So the recursive definition acts like simple definition.
If I clear the environment, it works as expected:
➜ ~ env -i make
echo Test
Test
I couldn't find any mention that recursively-expanded variable, when defined with same name as environment variable, will act like simply-expanded variable.
So the questions are:
Why the observed behavior?
How to implement the desired behavior?
Update: to clarify — I don't want to use ?= since the options are configuration options I want them to come strictly from Makefile and not from environment.
Any variable which is in the environment when make starts, will be exported to the environment of any command make runs (as part of a recipe, etc.) In order for make to send the value of the variable to the command, make first has to expand it. It's not acting like a simply-expanded variable. It's just that running a command forces the expansion.
This is kind of a nasty side-effect but I'm not sure there's anything that can be done directly: this behavior is traditional and mandated by POSIX and lots of makefiles would break if it were changed.
You have two choices I can think of. The first is to use the unexport make command to tell make to not send that variable in the command's environment.
The second is to change the name of the variable in make to something that is not a valid environment variable: make will only export variables whose names are legal shell variables (contain only alphanumeric plus _). So using a name like VAR-local instead of VAR would do it.
The question appear to be extremely clear in the title but the actual request get lost in details so the only other reply left it mostly unanswered. Directly answering to the question in the title, which is very interesting, to define a variable in a Makefile with same name as environment variable you can get its value with printenv:
PATH=${shell printenv PATH}:/opt/bin
echo:
echo $(PATH)
Other techniques to achieve the same result without relying on evaluation with external commands are welcome.