How to pass user defined parameters from command line

Hello, just another +1 from us. We need this feature to be able to pass different variables from our CI environment to the test(s).

1 Like

Another +1

kazurayam said:

Here is my approach to the same issue:
http://forum.katalon.com/discussion/5796/command-line-argument-dkatalon-user-home-xxxx

I hope a single option -Dkatalon.user.home= supported by future Katalon Studio Console Mode

>.\katalon.exe -Dkatalon.user.home=C:\Users\myname\tmp\blue ...

in the properties file you want to write whatever parameters you like:

GlobalVariable.URL=http://10.10.10.10

GlobalVariable.Title=Passing Parameters from Jenkins to Katalon


In the TestLister, you can write code to load the properties and overwrite the Global variables yourself. My post describes how I implemented this.

[http://forum.katalon.com/discussion/5780/katalon-properties-file-and-jvm-system-property-katalon-user-home](http://forum.katalon.com/discussion/5780/katalon-properties-file-and-jvm-system-property-katalon-user-home#latest "Link: http://forum.katalon.com/discussion/5780/katalon-properties-file-and-jvm-system-property-katalon-user-home#latest")  

  

Here, katalon.user.home will have path to the blue environment file and value from this file will be over written to global variables …correct?

krishnaprasad,

Here, katalon.user.home will have path to the blue environment file and value from this file will be over written to global variables …correct?

Yes, you understand correctly what I hoped at March 2018.

Let me note:

  1. In April 2018, Katalon Studio 5.4.0 introduced the -executionPropfile= switch as described at https://docs.katalon.com/display/KD/Console+Mode+Execution
  2. Katalon Studio 5.4+ does NOT support the -Dkatalon.user.home= switch which I proposed.

Both ideas (-executionProfile and -Dkatalon.user.home) intended to implement a feature of overwriting global variables dynamically at runtime. These 2 approaches are similar, but not identical. The -executionProfile approach requires the new settings is still managed by Katalon Studio. The -Dkatalon.user.home approach accepts the new settings from anywhere: out of Katalon Studio’s control.The Katalon team has chosen the -executionProfile approach and I respect it.

The -executionProfile= approach requires the new settings are still managed by Katalon Studio. If you want to set a credential (username/password pair) in the Execution Profile, you will want to encrypt it. Katalon Studio does provide a encryption feature as described at https://docs.katalon.com/display/KD/Working+with+Sensitive+Text

However some people argue that the Katalon’s encryption is not strong enough:

I think that it would be best secure if you entirely exclude the credential information out of the Katalon’s project. My -Dkatalon.user.home= approach is meant for that.

It depends how much of security you require for the testing fixtures. I do not like a username/password pair in the testing fixture to be visible as plain text. But I would accept it if encrypted even though the Katalon’s encryption method is not superior. Because, in my case, the credentials in my testing fixture are not so much serious.

1 Like

You can also define environment variable (with path to external configuration or properties file) in the session will be used to execute Katalon studio and then in the TestListener read the value of variable (path to the file), load that file and override settings for project, Global variables etc. To create new GlobalVariable I used metaprogramming:

void addGlobalVariable(String name, def value) {
    MetaClass mc = script.evaluate("internal.GlobalVariable").metaClass
    String getterName = "get" + name.capitalize()
    mc.static."$getterName" = { -> return value }
    //mc.static."$name" = value
}

It’s possible to add getter/setter as new methods to GlobalVariable class or add new field (commented in this example)

Than in the script code you can use GlobalVariable.VarName where the VarName you new variable.

7 Likes

That’s pretty sweet, @Sergii

Upvoted.

Sergii Tyshchenko said:

You can also define environment variable (with path to external configuration or properties file) in the session will be used to execute Katalon studio and then in the TestListener read the value of variable (path to the file), load that file and override settings for project, Global variables etc. To create new GlobalVariable I used metaprogramming:

void addGlobalVariable(String name, def value) {
MetaClass mc = script.evaluate("internal.GlobalVariable").metaClass
String getterName = "get" + name.capitalize()
mc.static."$getterName" = { -> return value }
//mc.static."$name" = value

}


  

It's possible to add getter/setter as new methods to GlobalVariable class or add new field (commented in this example)

Than in the script code you can use GlobalVariable.VarName where the VarName you new variable.

  

What is the ‘script’ variable in your example? It would be nice if others can execute your script for their cases.

+1
I would love to be able to pass user defined parameters to the test suite through the command line. Currently, I am running a test suite through Jenkins, and I would like to take advantage of parameterizing my Jenkins job so that my test suite can execute more accurately to my needs. I would use the parameters defined in my Jenkins job, and pass them into the batch command line for the test suite to use.

+1 From here also.

+1 from me as well, in our case it would be nice to be able to run the same test suite for multiple environments.

1 Like

+1 Our CI-CD system spins up dynamically named environments, and URLs based on branch names. It isn’t possible to know what is and isn’t going to be built and preload all these options as profiles within the GUI. It is absolutely necessary to be able to provide a minimum set of variables at CLI execution.

dynamically named environments, and URLs based on branch names.

Could you please provide an example of this?

The developer commits a feature branch to the repository.
Jenkins builds an EC2 instance, registers an ssl cert, and deploys the build.
the url is https://{{ branch_name }}-devui.windsorcircle.com

or

locally we frequently spin up multiple stacks to compare version1 to version2. As such the container names are generated dynamically

app_test_latest_branch1
app_test_latest_branch2

where each is accessible from a unique port
branch1 on http://localhost:8000
branch2 on http://localhost:8001

if I copy the entire source to tmp it functions as a workaround

Aaron,

the url is https://{{ branch_name }}-devui.windsorcircle.com

I see you have 2 problems to solve.

Problem1 : you need to be informed of the branch_name which Jenkins checked out and started to build, but how?

Problem2 : you need to generate the url string which contains the value of the branch_name, and pass it to the test suites in Katalon Studio, but how?

As for Problem1, Jenkins creates OS Environment variable **GIT_BRANCH . **This env variable is accessible for shell scripts that invokes katalon.exe. See

As for Problem2, your shell script will create another OS Environment variable (e.g. URL) , and your Test Listener or Test Case refers to it by

String url = System.getenv('URL')

Aaron,

I have made a demo project and published it at

----------

The Git repository URL which Jenkins to clone

Shell script which Jenkins invokes:

echo GIT_BRANCH="${GIB_BRANCH}"   # e.g. 'origin/master'export url=https://${GIT_BRANCH##origin/}-devui.windsorcircle.comecho url=$urlexport KATALONSTUDIO_HOME="/Applications/Katalon Studio.app/Contents/MacOS"./run_console_mode.sh

run_console_mode.sh

#!/bin/bashecho Environment variable KATALONSTUDIO_HOME="$KATALONSTUDIO_HOME"echo Environment variable url="$url"PROJECT_DIR=`pwd`echo PROJECT_DIR="$PROJECT_DIR"cd "$KATALONSTUDIO_HOME"./katalon -noSplash -runMode=console -summaryReport -projectPath="$PROJECT_DIR" -testSuiteCollectionPath="Test Suites/TSC" -reportFolder="Reports" -reportFileName=console_modeexitCode=$?cd "$PROJECT_DIR"echo $exitCodeexit $exitCode

Test Listener

import com.kms.katalon.core.annotation.BeforeTestCaseimport internal.GlobalVariable as GlobalVariableclass TL {		@BeforeTestCase	void beforeTestCase() {		if (System.getenv('targeturl') != null) {			GlobalVariable.URL = System.getenv('targeturl')		}	} }

Test Case

import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUIimport internal.GlobalVariable as GlobalVariableWebUI.comment(">>> GlobalVariable.URL is ${GlobalVariable.URL}")WebUI.openBrowser('')WebUI.navigateToUrl(GlobalVariable.URL)WebUI.delay(3)WebUI.closeBrowser()

The console output from Jenkins

...+ export url=https://master-devui.windsorcircle.com+ url=https://master-devui.windsorcircle.com+ echo url=https://master-devui.windsorcircle.comurl=https://master-devui.windsorcircle.com+ export 'KATALONSTUDIO_HOME=/Applications/Katalon Studio.app/Contents/MacOS'+ KATALONSTUDIO_HOME='/Applications/Katalon Studio.app/Contents/MacOS'+ ./run_console_mode.shEnvironment variable KATALONSTUDIO_HOME=/Applications/Katalon Studio.app/Contents/MacOSEnvironment variable url=https://master-devui.windsorcircle.com...
1 Like

@4280-kazurayam

PROJECT_DIR=`pwd`

try to avoid using the back-tick form. it is working (almost) well but:
- it is not POSIX compliant
- building more complex commands can give you serious headache if you do a mistake

you can try the modern form instead:

PROJECT_DIR=$(pwd)

The only issue I had was giving the relevant portion of the URL to Katalon.
Reading in a series of environment variables is a cumbersome but acceptable workaround.
your example includes testurl and url as names for the environment variable, guessing that was an accident.

+1 from me, nothing to add to the discussion but a sign that’s a wanted feature by many