This plugin adds an ability to perform REST over HTTP calls to Cadence vManager as a step in your build.

Plugin Dependency

Please make sure you have the dashboard-view plugin installed on your Jenkins before trying to install this plugin.

Also, in case you want to chart over the runs results, install the Junit Plugin as well.

Why this plugin ?

Cadence vManager (starting version 14.1 and above) is now exposing a REST API (vAPI) for performing automation queries and updates for its regression/test and coverage data. This plugin enables you to add a remote execution for extracting runs information, reports data or even launching new sessions as part of your build process.

Features

Free-style job plugin (can perform all vManager API call).

Support static/dynamic API calls

Support dynamic authentication per user id.

Special build step for performing launch of vsif files dynamically.

Support Dashboard portal for showing the session status. (plugin ver 1.9 and above)

Limitations

The plugin support for remote launching of vsif will be supported for Incisive 14.1 S5 and above.

Configuration

After installing the plugin you'll get two new steps in the build step selection.

A new step types

Choose "vManager API" if you need a free-style vAPI call to sends dynamic json input and receive a json output.

Choose "vManager Session Launcher" if you need to add a step for remote launching vsif (one or more).

Usage

vManager API

The step takes care for the following:

Authentication.

Defining the API call.

Defining the json input string for the API (static/dynamic).

Saving the API result (json format) into the workspace.

The below is an example of defining a static vAPI call for getting a list of runs with session id equals to 1 or 2:

Adding static vAPI input

The below is an example of defining a dynamic vAPI call:

Adding dynamic vAPI input

In case of a need in dynamically change the jSON input for the API per job, the pre-job should place into the workspace directory a file with the relevant jSON string to be sent to the vAPI. The input file should be place into the workspace directory. In case this field is empty, The file name need to be: $BUILD_NUMBER..$BUILD_ID.vapi.input

Please fill this field only in case, you want to hard code the input file name, to be consist across all builds.

vManager Session Launcher

The step takes care for the following:

Authentication.

Launching a vsif that is located on the NFS and is available to vManager Server.

The below is an example of defining a static vsif call.

Launching a static vsif file

The below is an example of defining a dynamic launch call with multiple vsif files.

Launching more than one vsif file dynamically

In case of a need in dynamically selecting the vsif files to get launched per job, the pre-job should place into the workspace directory a file with the full paths of the relevant vsif files to be launched, new line for each additional vsif file. The input file should be place into the workspace directory. In case this field is empty, The file name need to be: $BUILD_NUMBER.$BUILD_ID.vsif.input Please fill this field only in case, you want to hard code the input file name, to be consist across all builds.

Setting the build to wait till all session end execution:

In case you want to hold the build till the session end its execution on the vManager side, please check the 'wait for launched session to end" check box.

The above setup allow you to select how the build will behave in each of the state where the session stop from running:

ContinueIn case you select to continue, the build will assume (on the chosen state) for a given session that it can continue and finish the wait on this specific session.Please note that in case there are multiple sessions that are being executed by this step, the build will wait till all sessions got into a state that allow it to continue.

IgnoreIn case you select to continue, the build will assume (on the chosen state) for a given session that it can ignore the chosen state and keep waiting for other state (until get the 'completed' state).

FailIn case you select to fail, the build will assume (on the chosen state) for a given session that it should mark this build as a failure build. Note: If you have multiple sessions on this build step, it is enough for one single session to be marked as 'failed' in order to mark the entire build as a failed build.

Other Waiting Considerations1. When all sessions on this build step are having the state 'completed' the build will be marked as success.2. When the vManager server goes down, the build step will keep waiting till the server will go back up. The build step will only change its state based on sessions state changes.3. If the session was manually deleted on the vManager server, before reaching into final state, the build will be marked as a failure build.4. In any case, if the number of minutes waiting is bigger than the timeout set here, the build will marked as a failed build.

Add support in Junit Plugin and Test Charting

The launch Session Plugin is also capable of placing an XML file in the format of Junit Test Report. The XML file name will besession_runs.xml - This format let 'Junit Plugin" chart over each build. In order to activate this:

1.After activating the "wait for session to end", check the "Generate JUnit Result" checkbox. You can also add custom Runs' attributes to the report using this configuration.

2.Install the plugin "Junit Plugin". Add a final build step to pick */.session_runs.xml from the workspace.

This will give you a detail summary of the build, and an aggregated charting over your entire builds. See below.

Dashboard

The vManager Plugin also support a new Dashboard portal using the Dashboard-view plugin. The new portal reflects the session's states launched by the various builds:

To enable the new portal, select "vManager Latest Sessions" from the Dashboard drop-down.

Authentication

defining the connection settings

In case of a need in dynamically selecting the user name per job, the pre-job should place into the workspace directory a file with single line that contains the userid to be used. The file name should be: $BUILD_NUMBER.$BUILD_ID.user.input The job will pick the userid which is in the file, and connect to vAPI using this userid and the vAPI secret key.

Change Log

Version 2.4.9 (Sep 26, 2017)

Add an option to support the new 17.10 capability of sourcing an alias file for env variable per user before launching a session.

Version 2.4.7 (Feb 22, 2017)

Add an option to mark Jenkins Job as "Failed" when all runs in session are also failed.

Version 2.4.5 (Dec 9, 2016)

Add JUnit support in up to 100K run's for the XML report.

Fix special characters for JUnit XML.

Version 2.4.3 (Oct 26, 2016)

Add an option to mark build as "Failed" when all runs in session are also failed.

Version 2.4.2 (Sep 20, 2016)

Fixed a crash when saving the Jenkins Global Configuration screen.

Version 2.4 (Aug 23, 2016)

Changed Junit XML output to mark 'skip' (yellow) on any run state other than 'passed' or 'failed'.

Version 2.3 (Aug 19, 2016)

Add session generated unique id as part of the session name in the dashboard.

Change the JUnit XML file name to be consisted across all builds.

Upgrade the build POM to Jenkins 2.14

Version 1.10 (July 24, 2016)

Add support for detailed error messages coming back from vAPI such as missing env variables.

Add support for JUnit Results XML even when build marked as failed.

Version 1.9 (July 18, 2016)

Add support in dashboard-view plugin.

Add support for JUnit Results XML

Version 1.8 (July 12, 2016)

Add support for the build step to wait till Session ends.

Create session_list.output per job that contain the session ID launched.

Version 1.7 (July 5, 2016)

Add support for Session Launch with the user's Linux account credentials.

Version 1.6 (May 20, 2015)

Add support for VSIF variables.

Version 1.5 (May 14, 2015)

Add support in timeout configuration.

Version 1.4 (Sep 11, 2014)

Add support in PUT & GET API.

Version 1.3 (Aug 24, 2014)

Add support in vAPI over SSL.

Version 1.2 (Aug 14, 2014)

Update code for supporting the automatic launching of vAPI using vManager Server.