I'm currently setting up Fitnesse, with FitSharp and the .net implementation of dbfit.
I understand how to trigger tests or suites from the submission of a URL, or from a command line, eg:
java -jar fitnesse-standalone.jar -c "MyTest?test&format=text"
What I can't figure out is how to submit variable values in this query string.
So, if I have a test containing a Sql statement which has a Fitnesse variable referenced in the Where clause, and the value of this variable is defined in a sibling static page, I would like to be able to run this test from the command line and submit a value for this variable which overrides the value in the static page. Something like:
java -jar fitnesse-standalone.jar -c "MyTest?test&format=text&${myVar}=abc"
Is this possible at all?
Thanks
Mark
There are two ways to pass variables from the command line, both involving environment variables.
(1) Define an environment variable (or identify one that already exists). You can use general purpose system variables (like %TMP% or %HOMEPATH%) or your own user-defined variables (e.g. %JAVA_HOME%) or create your own. My short Fitnesse launcher (a .CMD file) is this:
set SEED=%RANDOM%
set FITNESSE_PORT=9999
java -jar fitnesse-standalone.jar -p %FITNESSE_PORT% -e 0
The FITNESSE_PORT variable is defined just for use in the very next line. The SEED variable, however, does magic: it allows several people to run the same test simultaneously by generating unique values per session. (This assumes that each user runs their own FitNesse server, so each will thereby have a unique session.) I then instrument my tests by defining ids relative to the seed, e.g.
!define TestClient (MyTestClient_${SEED})
(2) Pass an environment variable setting scoped to just the java process that instantiates the FitNesse runner. This technique gives you precisely the same results with just a different implementation:
java -DSEED=%RANDOM% -jar fitnesse-standalone.jar -p %FITNESSE_PORT% -e 0
This yields precisely the same result within FitNesse, giving you access to the %SEED% environment variable as ${SEED}.
For more, see part 2 of my seven-part series on Acceptance Testing with FitNesse published on Simple-Talk.com.
Related
I want to create some "build traceability" functionality, and include the actual bazel command that was run to produce one of my build artifacts. So if the user did this:
bazel run //foo/bar:baz --config=blah
I want to actually get the string "bazel run //foo/bar:baz --config=blah" and write that to a file during the build. Is this possible?
Stamping is the "correct" way to get information like that into a Bazel build. Note the implications around caching though. You could also just write a wrapper script that puts the command line into a file or environment variable. Details of each approach below.
I can think of three ways to get the information you want via stamping, each with differing tradeoffs.
First way: Hijack --embed_label. This shows up in the BUILD_EMBED_LABEL stamping key. You'd add a line like build:blah --embed_label blah in your .bazelrc. This is easy, but that label is often used for things like release_50, which you might want to preserve.
Second way: hijack the hostname or username. These show up in the BUILD_HOST and BUILD_USER stamping keys. On Linux, you can write a shell script at tools/bazel which will automatically be used to wrap bazel invocations. In that shell script, you can use unshare --uts --map-root-user, which will work if the machine is set up to enable bazel's sandboxing. Inside that new namespace, you can easily change the hostname and then exec the real bazel binary, like the default /usr/bin/bazel shell script does. That shell script has full access to the command line, so it can encode any information you want.
Third way: put it into an environment variable and have a custom --workspace_status_command that extracts it into a stamping key. Add a line like build:blah --action_env=MY_BUILD_STYLE=blah to your .bazelrc, and then do echo STABLE_MY_BUILD_STYLE ${MY_BUILD_STYLE} in your workspace status script. If you want the full command line, you could have a tools/bazel wrapper script put that into an environment variable, and then use build --action_env=MY_BUILD_STYLE to preserve the value and pass it to all the actions.
Once you pick a stamping key to use, src/test/shell/integration/stamping_test.sh in the Bazel source tree is a good example of writing stamp information to a file. Something like this:
genrule(
name = "stamped",
outs = ["stamped.txt"],
cmd = "grep BUILD_EMBED_LABEL bazel-out/volatile-status.txt | cut -d ' ' -f 2 >\$#",
stamp = True,
)
If you want to do it without stamping, just write the information to a file in the source tree in a tools/bazel wrapper. You'd want to put that file in your .gitignore, of course. echo "$#" > cli_args is all it takes to dump them to a file, and then you can use that as a source file like normal in your build. This approach is simplest, but interacts the most poorly with Bazel's caching, because everything that depends on that file will be rebuilt every time with no way to control it.
I am trying to pass more than nine parameters from Jenkins to JMeter4.0.
As I was reading, I found out that JMeter does not accept more than 9 parameters. As a workaround, I want to pass all the parameters as a string and split it in JMeter BeanShell.
java -jar -Xms512m -Xmx2048m C:\JMeter4\bin\ApacheJMeter.jar -Jjmeter.save.saveservice.output_format=csv -Jjenkinsparams="%Timetorun%,%Users%" -n -t %JMeterPath%\bin\tests\tests.jmx -l %WORKSPACE%\Results.csv
The tests run on a Windows machine. From this call I have
jenkinsparams = "300,2"
I use a BeanShell PreProcessor like this:
String line = "${__P(jenkinsparams)}";
String[] words = line.split(",");
vars.put("timetorun",words[0]);
vars.put("users",words[1]);
log.info(words[1]);
log.info(users);
I tried few log.info to check the values. For words[1] I have the correct value sent from Jenkins: 2. For the users the value displayed is: void.
I am trying to use it for Number of Threads as: ${__P(users,1)}.
What am I doing wrong? The values clearly arrive from Jenkins but I have a problem passing it to my variable. Thank you
You don't have a script variable named users, so you should either log words[0]:
log.info(words[0]);
Or you can log the value of JMeter variable called users:
log.info(vars.get("users"));
Or you can assign words[0] to variable called users:
String users = words[0];
log.info(users);
Also you are saving it as variable, not property, so you can retrieve it elsewhere in script as
${users}
The syntax __P refers to property, so if you want to use it as property, you need to change how you are saving it:
props.put("users", words[1]);
If you do that, ${__P(users,1)} should work
Now, if you want to use this value as number of threads, then you need to do this:
Have Setup thread group with 1 thread, and your script
In the script you must save users as property, otherwise it won't pass between threads
Next thread group then can use it as number of threads
As long as your command line fits into 8191 characters it should not be a problem to pass as many arguments to JMeter as you want, here is an evidence from Debug Sampler and View Results Tree listener combination
So keep calm and pass as many parameters as needed via -J command line arguments.
Be aware that starting from JMeter version 3.1 users are recommended to use JSR223 Test Elements and Groovy language instead of Beanshell so going forward please consider switching to Groovy.
I'm using grails 3.2.6. I'm writing a custom grails command. It's a command and not a script because I need access to object in the spring application context in the command. I would like for my command to accept command line arguments with values such as "name" and "group" and "id". For example, I'd like to be able to run the command like this:
grails run-command process-group --name=foo --group=bar --id=2
However, when I do this, my command implementation class doesn't seem to have access to any of these arguments (name, group, or id). I've tried accessing them through the args attribute that comes from the GrailsApplicationCommand trait, but that is empty. I've also tried accessing it through various methods of the CommandLine object that is accessible through executionContext.commandLine object which also comes from the GrailsApplicationCommand trait. However, everything there seems to be empty as well (undeclaredOptions is empty, remainingArgs is empty, rawArguments just has my command name which is "process-group", etc.). If I remove the leading "--" from my argument names like this:
grails run-command process-group name=foo group=bar id=2
then the args attribute contains 3 entries: ["name=foo", "group=bar", and "id=2"]. I suppose that I could implement my command this way (no leading "--" on the command arguments), but it's kind of ugly, and it also means that I have to parse the arguments myself. The grails docs (http://docs.grails.org/latest/guide/single.html#creatingCustomCommands) say that, "Since Grails 3.2.0, commands have similar abilities as scripts in regards to retrieving arguments, template generation, file access, and model building." I'm interested in the retrieving arguments part of that statement. The examples shown in the documentation for scripts (not commands) show (http://docs.grails.org/latest/guide/single.html#creatingCustomScripts) how to declare parameters that a script will take from the command line. For example, this command line is supposed to work with a custom script that declares the "force" parameter for the generate-all custom script:
grails generate-all MyClass --force
This all seems to be tied to the use of the description() method in the script:
description( "Generates a controller that performs CRUD operations and the associated views" ) {
usage "grails generate-all <<DOMAIN CLASS>>"
flag name:'force', description:"Whether to overwrite existing files"
argument name:'Domain Class', description:'The name of the domain class'
}
However, there doesn't seem to be a description() method available for use for custom commands as there is for custom scripts. I just confused about how the grails docs state that retrieving arguments is supposed to now work the same for both custom scripts and custom commands, yet I can't seem to retrieve arguments from a custom command like I can from a custom script. Is there a way that I can retrieve the arguments for a custom command just like it can be done for a custom script?
Set the properties using the -D option:
-Dsample.message=foo
Grab the system properties using the follow code:
System.properties['sample.message']
Link to the where I found this example:
Passing Properties
I want to read a variable from CSV and use that value into another variable.
Example:
I have a variable as:
${url}: wwww.$(value_from_csv}.com
and secondary url ${url}/xyz
In my Jmeter script, ${value_from_csv} is not passed.
What I am missing?
Observed that CSV Dataset Config values are not passed (not available) to any of the Config Elements irrespective of the order of the components (Config Elements) in JMeter Test Plan (checked with User Defined Config & MongoDB Source Config), though passed to Samplers.
so, suggested the OP to define the value in jmeter.properties instead of a CSV file, so we can access user.host in MongoDB Source Config.
Steps:
Add user.host=address in jmeter.properties
Restart Jmeter
Add ${__P(user.host,)} in Server Address List field in MongoDB Source Config
Note: In case of running JMeter script from Jenkins, property will be picked by the script, from jmeter.properites file.
MongoDB Source Config is initialized before any JMeter Variables so the only way to make it dynamic is using JMeter Properties instead.
You can set a JMeter Property in 2 ways:
Define it in user.properties file like:
server.address.1=some.ip.or.hostname.1
server.address.2=some.ip.or.hostname.2
Pass the properties via -J command-line arguments like:
jmeter -Jserver.address.1=some.ip.or.hostname.1 -Jserver.address.2=some.ip.or.hostname.2 ....
See Apache JMeter Properties Customization Guide for more information on using JMeter Properties
It is my understanding that when invoking spawn "string command" in xmonad, the argument "string command" is actually passed to /bin/sh.
Is there a way to change this behavior ?
More specifically, is it possible to make the instance of the interpreter called by spawn aware of some predefined environment variables (typically, SSH_AUTH_SOCK and SSH_AGENT_PID)?
Of course, it is always possible to resort to spawn "$VARIABLE=stuff; export $VARIABLE; string command", but it bothers me that the variabe should be created and exported each time.
Strictly answering your first question, the safeSpawn function in XMonad.Util.Run (in xmonad-contrib) will run a command without passing it to a shell.
However, that shouldn't make much of a difference as far as environment variables are concerned. In both cases, the spawned command should inherit the environment of the XMonad process (which the shell's startup/rc files could tweak in the case of spawn).
It's possible to set the environment of the started process with general Haskell facilities, e.g. System.Posix.Process.executeFile (and System.Environment.getEnvironment if you want to make a modified copy of the XMonad process' environment).