Triggering Silk Central from a CI Server

This section describes how you can better integrate Silk Central into your continuous integration (CI) processes by triggering executions on Silk Central from your CI server using a Gradle script.

Additionally, this section describes how to get results from Silk Central and how to use these results in your build process.

To trigger executions on Silk Central from a CI server and to collect the execution results from Silk Central, you need to add a Gradle script with the appropriate commands to your source control. You can download the silkcentral.gradle file from the Silk Central UI. Navigate to Help > Tools and click Gradle script for CI server integration.

You can configure the following properties in the Gradle script:
Property Description
sc_executionNodeIds The comma-separated list of execution plans to be started. This list should not contain folders. For example 22431,22432,22433.
sc_host The Silk Central host. For example http://[sc_server_name]:19120.
sc_token The web-service token for user authentication. You can generate the web-service token in the Settings Page of the Silk Central UI. To access this page, hover the mouse cursor over the user name in the Silk Central menu and select User Settings. For example 80827e02-cfda-4d2d-b0aa-2d5205eb6eq9.
sc_sourceControlBranch Optional: Specify this property to check out a specific branch. If no branch is specified, the setting of the execution plan is used.
sc_ buildName Optional: The build for the run. If no build is specified, the setting of the execution plan is used. You can only set this property for execution plan nodes, not for folders.
sc_StartOption Optional: The tests that should be executed. If this is not specified, all assigned tests will be executed. The allowed values are:
  • ALL
  • FAILED
  • NOT_EXECUTED
  • NOT_EXECUTED_SINCE_BUILD
  • FAILED_NOTEXECUTED_SINCE_BUILD
  • HAVING_FIXED_ISSUES
The default value is ALL.
sc_sinceBuild Optional: The name of the build since which tests have not been executed. Specify this property if the sc_StartOption property is set to FAILED_NOTEXECUTED_SINCE_BUILD or NOT_EXECUTED_SINCE_BUILD.
sc_collectResults Optional: If true, the script will wait until the Silk Central execution is finished and will write results files in JUnit format. If false, the script will trigger the execution and will finish without waiting for the results. The files will be stored in the subfolder sc_results. The default value is true. Boolean.
sc_startDelay Optional: The start delay in seconds. Can be specified if you have more than one execution plan to execute. The execution plans will be started sequentially with the specified delay between starts. This can be helpful if you need to minimize the workload on the test environment at startup, for example when starting a virtual machine or when installing the application under test. The default value is 0.

You can either specify the properties directly in the script or pass them when triggering the script.

All additional project properties that are specified when triggering the script will be passed as parameters to Silk Central and are used for the execution. This enables you to parameterize the executions in Silk Central with values from the build server.

For example, if your build starts a test server in Docker, you can pass the URL to this server by specifying the property in the command line:
-PmyServerUrl=http://docker:1234

Command Line Example

The following command launches the script from the command line, starting the execution tree nodes 22431,22432, and 22433 on localhost and using the web-service token 80827e02-cfda-4d2d-b0aa-2d5205eb6ea9 for authentication:
gradle -b silkcentral.gradle
:silkCentralLaunch -Psc_executionNodeIds='22431,22432,22433'
-Psc_host='http://localhost:19120'
-Psc_token='80827e02-cfda-4d2d-b0aa-2d5205eb6ea9'

For specific information on triggering executions on Silk Central from Jenkins, see Triggering Executions from Jenkins. For specific information on triggering executions on Silk Central from TeamCity, see Triggering Executions from TeamCity.