Does anybody know how I can run gauge with a custom argument to command line and handle it in python plugin?
For example:
When I launch gauge, I want also pass additional argument/flag to command line (> gauge run specs 17) and then handle it and use in my python code before/or when suites starts
Solution was found.
I just added session enviroment variable.
https://github.com/getgauge/docs.gauge.org/blob/master/configuration.rst
You can add a property to env/default/default.properties and use that property as an argument.
E.g. gauge run --env ci specs
Reference: https://docs.gauge.org/latest/configuration.html#id1
Related
I want to use ctest from the command line to run my tests with memcheck and pass in arguments for the memcheck command.
I can run ctest -R my_test to run my test, and I can even run ctest -R my_test -T memcheck to run it through memcheck.
But I can't seem to find a way to pass arguments to that memcheck command, like --leak-check=full or --suppressions=/path/to/file.
After reading ctest's documentation I've tried using the -D option with CTEST_MEMCHECK_COMMAND_OPTIONS and MEMCHECK_COMMAND_OPTIONS. I also tried setting these as environment variables. None of my attempts produced any different test command. It's always:
Memory check command: /path/to/valgrind "--log-file=/path/to/build/Testing/Temporary/MemoryChecker.7.log" "-q" "--tool=memcheck" "--leak-check=yes" "--show-reachable=yes" "--num-callers=50"
How can I control the memcheck command from the ctest command line?
TL;DR
ctest --overwrite MemoryCheckCommandOptions="--leak-check=full --error-exitcode=100" \
--overwrite MemoryCheckSuppressionFile=/path/to/valgrind.suppressions \
-T memcheck
Explanation
I finally found the right way to override such variables, but unfortunately it's not easy to understand this from the documentation.
So, to help the next poor soul that needs to deal with this, here is my understanding of the various ways to set options for memcheck.
In a CTestConfig.cmake in you top-level source dir, or in a CMakeLists.txt (before calling include(CTest)), you can set MEMORYCHECK_COMMAND_OPTIONS or MEMORYCHECK_SUPPRESSIONS_FILE.
When you include(CTest), CMake will generate a DartConfiguration.tcl in your build directory and setting the aforementioned variables will populate MemoryCheckCommandOptions and MemoryCheckSuppressionFile respectively in this file.
This is the file that ctest parses in your build directory to populate its internal variables for running the memcheck step.
So, if you'd like to set you project's options for memcheck during cmake configuration, this is the way to got.
If instead you'd like to modify these options after you already have a properly configured build directory, you can:
Modify the DartConfiguration.tcl directly, but note that this will be overwritten if cmake runs again, since this file is regenerated each time cmake runs.
Use the ctest --overwrite command-line option to set these memcheck options just for that run.
Notes
I've seen mentions online of a CMAKE_MEMORYCHECK_COMMAND_OPTIONS variable. I have no idea what this variable is and I don't think cmake is aware of it in any way.
Setting CTEST_MEMORYCHECK_COMMAND_OPTIONS (the variable that is actually documented in the cmake docs) in your CTestConfig.cmake or CMakeLists.txt has no effect. It seems this variable only works in "CTest Client Scripts", which I have never used.
Unfortunately, both MEMORYCHECK_COMMAND_OPTIONS and MEMORYCHECK_SUPPRESSIONS_FILE aren't documented explicitly in cmake, only indirectly, in ctest documentation and the Testing With CTest tutorial.
When ctest is run in the build, it parses the file to populate its internal variables:
https://cmake.org/cmake/help/latest/manual/ctest.1.html#dashboard-client-via-ctest-command-line
It's not clear to me how this interacts with
In our Katalon Studio project we have a test case.
We like that test case to accept a parameter from the command line when running the test suite.
For example, we like to run the same test case one time with parameter=A and another with parameter=B.
This will enable our Jenkins to run different tests without the need to duplicate test cases again and again.
Is there a way to do it?
Actually, you can't specify your parameters in the command line. But it seems to be in demand by the community (Katalon - How to pass user defined parameters from command line)
Solution :
You can define your parameters in profiles. Each profile can contains the same parameters with different values, and can be chosen during the Test Suite execution.
You can choose the profile you need manually or by passing it in command line. To do it you only have to use the -executionProfile option:
katalon -noSplash -runMode=console -consoleLog -noExit -projectPath="C:\MY_PATH" -retry=0 -testSuitePath="Test Suites/MY_TEST_SUITES" -executionProfile="Profile_A"
Finally, don't forget to convert your step input Variables into Global Variables where you need in your Test Case. You can do that manually or by script :
import internal.GlobalVariable as GlobalVariable
GlobalVariable.my_variable
docs: Katalon Docs - Execution Profile (v5.4+)
Hoping it will help you.
Like post above but in more way of showing where to look for the answers.
After You open Your Project, look for Profile :
Need to add to your script(it should be added be default be still remember if you will get error about missing keyword)
You are ready to make your "Build CMD"
From version 5.10, it is possible to override profile variables from the command line.
So, if you have a GlobalVariable.parameter=A as the default, you can add
-g_parameter=B
to the command line command to switch it to B.
My question is similar to this: Execute only one talend component. Except instead of using the Talend Open Studio, I want to be able to run a specific component from the shell executable I get from building the job.
I have set up my job in a way that if a component is succeeded, the OnComponentOk trigger is used to run the next component. To run the job I run sudo bash NAME_OF_THE_JOB.sh. Is it possible to run only one component, perhaps by passing arguments to the bash shell file?
A Talend job is a single java program. Components are translated to java functions. There are no arguments that allow you to execute a single component.
What you could do is write your job in such a way to execute a component whose name is passed via a context variable but it's not pretty.
You can test the component name passed via a variable named componentName using Run If triggers:
tRunJob_1
/
if("tRunJob_1".equals(context.componentName)
/
/
Start ---if("tJava_2".equals(context.componentName))-- tJava_2
\
\
if("tRest_1".equals(context.componentName))
\
tRest_1
As you can see, this can get very cumbersome, and requires you to know the component's name in order to run it.
You can then launch your job by passing the component name as argument :
sudo bash NAME_OF_THE_JOB.sh --context_param componentName=tJava_2
Currently, I use export JAVA_OPTS ... on the command line, but there seem to be other possibilities, using the build.sbt or an external property file.
I have found several relevant github issues here, here and here but the many options are confusing. Is there a recommended approach?
The approach you take to setting JVM options depends mainly on your use case:
Inject options every time
If you want to be able to specify the options every time you run your service, the two mechanisms are environment variables, and command line parameters. Which you use is mostly a matter of taste or convenience (but command line parameters will override environment variable settings).
Environment variables
You can inject values using the JAVA_OPTS environment variable. This is specified as a sequence of parameters passed directly to the java binary, with each parameter separated by whitespace.
Command line parameters
You can inject values by adding command line parameters in either of two formats:
-Dkey=val
Passes a Java environment property into the java binary.
-J-X
Passes any flag -X to the java binary, stripping the leading -J.
Inject options from a file which can be modified
If you want to end up with a file on the filesystem which can be modified after install time, you will want to use sbt-native-packager's ability to read from a .ini file to initialise a default value for Java options. The details of this can be seen at http://www.scala-sbt.org/sbt-native-packager/archetypes/cheatsheet.html#file-application-ini-or-etc-default
Following the instructions, and depending on the archetype you are using, you will end up with a file at either /etc/default, application.ini, or another custom name, which will be read by the startup script to add settings.
Each line of this file are treated as if they were extra startup parameters, so the same rules as mentioned earlier are still enforced; e.g. -X flags need to be written as if they were -J-X.
Inject options & code which never need to be changed
You can hardcode changes directly into the shell script which is run to start your binary, by using the SBT setting bashScriptExtraDefines, and following the details at http://www.scala-sbt.org/sbt-native-packager/archetypes/cheatsheet.html#extra-defines
This is the most flexible option in terms of what is possible (you can write any valid bash code, and this is added to the start script). But it is also less flexible in that it is not modifiable afterwards; any optional calculations have to be described in terms of the bash scripting language.
I'd like to be able to modify some build tasks in response to command line parameters. How do I (can I?) access command line parameters from the Build.scala file?
I don't think it's possible and you should rather resort to using input tasks or environment properties with -D.