[FEATURE-REQ] Use environment variable expansion in configuration of controllers and schedules

[bicschneider]

This would make it Matrix-build type and parameterized build compliant

[jonbrohauge]

Could this include the ability to dynamically add/insert the URL that the tests should aim for? My specific use case is as follows:

1. build web artifact
2. create new runtime environment for testing purposes
3. deploy web artifact onto new runtime
4. run UI tests on above website, injecting the URL
5. pass/fail tests
6. destroy runtime environment

[romanchetto]

Hello @bicschneider and @jonbrohauge . Thank you faor your advice.
Could you please provide more information or schemas and etc? I want to understand better, what you mean and discuss it with my supervisor. Thank you

[bicschneider]

in the configuration of the plugin enable usage of:

In job parameter section

LW_controller=http://leapworkcontroller.mycompany.com
LW_schIds=ajsdklf\nasdfk3ak\naskfl3
LW_schNames=My sch1\nMy sch1\nMy sch1

In the leapwork plugin

Controller: ${LW_controller}
ScheduleIds: ${LW_schIds}
ScheduleNames: ${LW_schNames}

The same for all options in the plugin

[bicschneider]

Could this include the ability to dynamically add/insert the URL that the tests should aim for? My specific use case is as follows:

1. build web artifact
2. create new runtime environment for testing purposes
3. deploy web artifact onto new runtime
4. run UI tests on above website, injecting the URL
5. pass/fail tests
6. destroy runtime environment

@jonbrohauge : I guess you scenario also require #13?

[jonbrohauge]

My guess is that yes, we need #13 as well, if it solves our need to pass on variable information. I.e.
We have a set of tests that we want to execute against different environments. The test suite itself does not know the URL of the browser tests it needs to perform. Passing the specific value of the URL in a specific execution of a Jenkins build is needed.
Something like this:

1. URL defined in Jenkinsfile/EnvVar
2. The value is passed to the plugin
3. The value is passed to the test executor/client
4. The value is passed to the test suite
5. The value is used in the test suite

The whole point is that the test suite itself does not know specifically where to point the "cannon", just that it should shoot towards the value in the place holder in the test suite itself.

I hope it makes sense.

[bicschneider]

@jonbrohauge .. Please add your comment to #13 as it relates more directly to that.. #13 enabled the pass of the variables. This issue is just related to Jenkins plugin variable expansion. Makes sense?