I have a JMeter script, where I have some user defined Variables like FILE_SAVE_PATH. This script should be started on a command line with parameter -J. So in the GUI, I changed the value for the variable FILE_SAVE_PATH to ${__P(FILE_SAVE_PATH, "C:\svn\trunk\dir")}, because the test should save there a file, but only on my machine. On the machine, where the script will be started from command line, it should save the file into another path.
My problem is now this: When I test this JMeter script on my machine in the GUI, I get an output of this:
About to replace in property of type: class org.apache.jmeter.testelement.property.StringProperty: ${__P(FILE_SAVE_PATH, "C:\svn\trunk\dir")}
2017/04/04 17:09:38 DEBUG - jmeter.testelement.property.AbstractProperty: Not running version, return raw function string
2017/04/04 17:09:38 DEBUG - jmeter.engine.util.ValueReplacer: Replacement result: ${__P(FILE_SAVE_PATH, "C:\svn\trunk\dir")}
But I think, the last line should be something like this:
2017/04/04 17:09:38 DEBUG - jmeter.engine.util.ValueReplacer: Replacement result: "C:\svn\trunk\dir"
So, how to change the test to get the result I want?
Escape every backslash with another one - C:\\svn\\trunk\\dir, or use unix slash, JVM's gonna handle it right: C:/svn/trunk/dir
And remove the doublequotes, they're not needed.
P.S. I presumed you're not using that notation in the Beanshell/JSR223 context. If you do - stop there and use the legit way to access properties.
Related
I would like to execute a gradle luqibase plugin diffChangelog task with my custom arguments from command line.
I DO NOT want to add/modify any of the project files, no modifications of build.gradle, no gradle.properties or such i just want to run a task and pass its parameters from command line and i am so far unable to do so i would like to distribute my script that executes this task in one bash file.
I have a problem even figuring out how to pass parameters to a gradle task, moreover even the format of the arguments is confusing - there are documentation snippets pointing that i should use camelCase or hyphenated version also zero/one/two hyphens are possible in the beginning . Additionally can either use -P or -D to pass arguments to gradle so far none of it seem to work it looks like the arguments are not being passed at all.
I would like to execute something like:
./gradlew diffChangelog --url=AA --username=BB --password=CC --reference-username=DD --reference-password=EE --reference-url=FF --changelog-gile=GG
Of course proper values will be provided by inline.
Is there a concise way to do so? So far googling up for the solution results in multiple complex explanations requiring modification of existing files and then passing arguments, is there really no way of just running a gradle task with arguments or am i missing something?
Update:
The error i am alyways getting is:
liquibase.exception.CommandValidationException: Invalid argument '--reference-url': missing required argument
You should check what end of line you have. This can sometimes be resolved by changing the end of line from from windows eol to linux.
Reference:
Unexpected error running Liquibase: Unexpected value [...] (options must start with a '--') && howTo? diff w/ properties file
I have a Terraform project that I was trying to use Jenkin's Custom Checkbox plugin (Custom Checkbox Parameter) with so that I can build separate applications dynamically using the same IaC, however, I'm getting the following error when passing in the name parameter for that plugin into the Terraform plan and apply commands.
syntax error: bad substitution
The idea for all this is just to click on "select all" or each individual app and run the build, and this will create the IaC for the given application(s).
I have a terraform plan that I am running as a smoke test to verify the parameters above are being passed in correctly before running the apply. This looks like the following:
sh 'terraform plan -var-file="terraform-dev.tfvars" -var "app_name=[${params[${please-work}]}]" -input=false'
The documentation for the plugin states that you can reference the items checked by using this format: "${params['please-work']}" which is what I've done above. That said, one caveat to this is that Im having to set the values in quotes for this to work since the variables are being set in the Terraform using list(string).
NOTE: I have tested that all this works if I just hardcode the app names with the escapes as following:
sh 'terraform plan -var-file="terraform-dev.tfvars" -var "app_name=[\\"app-1\\",\\"app-2\\"]" -input=false'
Again, what I need is for this to work with the -var "app_name=[${params[${please-work}]}]" without throwing that error.
If needed, here is the setup for the JSON that the plugin is using:
Additionally, I can see the values are being set the way I need them to be set when running the echo of echo "${params['please-work']}" on the initial build step. So these are coming back as "app-1", "app-2"
Again, all but that one bit is working and I've tried various ways to escape the needed strings to get this work and I need insight on a path forward. This would be greatly appreciated.
You are casting the script argument in your sh step method as a literal string, and therefore it will not interpolate the pipeline variable of type object params within the Groovy pipeline interpreter. You also are passing the variable value for the app_name with [] syntax (attempted list constructor?), which is not syntactically valid for shell, Terraform, or JSON, but is for Jenkins Pipeline and Groovy with undesired behavior (unclear what is desired here). Finally, please-work is a literal string and not a Jenkins Pipeline or Groovy variable, and since params is technically an object and not a Map, you must use the . syntax and not the [] syntax for accessors. You must update with:
sh(label: 'Execute Terraform Plan', script: "terraform plan -var-file='terraform-dev.tfvars' -var 'app_name=${params.please-work}' -input=false")
If another issue arises after fixing all of this, then it would be recommended to convert the plugin usage to the pipeline with a parameters directive, and also to probably remove the unusual characters e.g. - from the parameter name.
Thanks for helping me think through this, Matt. I was able to resolve the issue with the following shell script in the declarative pipeline:
sh "terraform plan -var-file='terraform-dev.tfvars' -var 'app_name=[${params['please-work']}]' -input=false"
This is working now.
I have seen many posts where people asking to access Bamboo variables in script but this is not about that.
I am defining a variable in Shell Script task, as below, and then I would like to access that variable in the subsequent maven task.
#!/bin/sh
currentBuildNumber=${bamboo.buildNumber}
toSubtract=1
newVersion=$(( currentBuildNumber - toSubtract ))
echo "Value of newVersion: ${newVersion}"
This one goes perfectly fine. However I have a subsequent maven 3 task where I try to access this variable by typing ${newVersion} I get below error
error 07-Jun-2019 14:12:20 Exception in thread "main" java.lang.StackOverflowError
simple 07-Jun-2019 14:12:21 Failing task since return code of [mvn --batch-mode -Djava.io.tmpdir=/tmp versions:set -DnewVersion=1.0.${newVersion}] was 1 while expected 0
Basically, I would like to automate the version number of the built jar files just by using ${bamboo.buildNumber} and subtracting some number so that I won't have to enter the new version number every time I run a build.
Appreciate your help... thanks,
EDIT: I posted the same question on Atlassian forum too... I will update this post when I get an answer there... https://community.atlassian.com/t5/Bamboo-questions/Bamboo-Access-script-variable-in-subsequent-maven-task/qaq-p/1104334
Generally, the best solution I have found is to output the result to a file and use the Inject Variables task to read the variable into the build.
For example, in some builds I need a SUFFIX variable, so in a bash script I end up doing
SUFFIX=suffix=-beta-my-feature
echo $SUFFIX >> .suffix.cfg
Then I can use the Inject Variables Task to read that file
Inject Variables Task
Make sure it is a Result variable and you should be able to get to it using ${bamboo.NAMESPACE.name} for the suffix one, it would be ${bamboo.VERSION.suffix}
I have encountered an error when running a batch file. It goes like this, I run test-setup.cmd which calls another batch file test-env.cmd
test-setup.cmd calls by using this line:
call %SCRIPT_HOME%\test-env.cmd
where SCRIPT_HOME is set up as SCRIPT_HOME=%~dp0
test-env.cmd has this line:
if [%TEST_HOME%] == [] set TEST_HOME=D:\Program Files\Test\test-02.2.3.Final
After running the test-setup.cmd a message appears like this:
Files\Test\test-02.2.3.Final was unexpected at this time
Note that I have setup the TEST_HOME in the system environment variables.
Please help, thank you.
The syntax of your if command is incorrect. It would work if %TEST_HOME% didn't contain any spaces, but since it does you must use double quotes:
if "%TEST_HOME%" == "" set TEST_HOME=D:\Program Files\Test\test-02.2.3.Final
Mind you, since you're just testing to see whether the variable exists, it would be a lot more efficient to do that directly:
if not defined TEST_HOME set TEST_HOME=D:\Program Files\Test\test-02.2.3.Final
When my program finds itself outdated, it runs the updater 'data1.bat'.
In this case, i found that cmd was completely ignoring the double quotes in the command
This is the line of code (with variables(Original)):
start "" "%dirofbatch%data1.bat" "%downloc%" "%dirofbatch%" "%lver%" "%lget%"
This is the line of code (with those variables expanded):
start "" "C:\Users\Hello\Desktop\Minecraft Client\Versions\4.7\data1.bat" "\\SERVER\Users\Test User\Minecraft Hunger Games Client v4.8" "C:\Users\Hello\Desktop\Minecraft Client\Versions\4.7" "4.7" "4.8"
Instead of working, it seems to see:
start "" C:\Users\Hello\Desktop\Minecraft User\Minecraft Hunger Games
I found that out when every-time it ran, it started minecraft on my desktop, tried to login with the user name "User\Minecraft", the password "Hunger" and then tried to login to the server "Games"...
Is it possible to pass parameters with spaces to another batch program without this happening?
It's a bug of START or better of cmd, if in the path of the command is a space and at least in one parameter it fails.
A workaround to add a CALL
start "" CALL "C:\Users\Hello\Desktop\Minecraft Client\Versions\4.7\data1.bat" "\\SERVER\Users\Test User\Minecraft Hunger Games Client v4.8" "C:\Users\Hello\Desktop\Minecraft Client\Versions\4.7" "4.7" "4.8"