The following plugin provides functionality available through Pipeline-compatible steps. Read more about how to integrate steps into your Pipeline in the Steps section of the Pipeline Syntax page.

For a list of other such plugins, see the Pipeline Steps Reference page.

Cadence vManager Plugin for Jenkins

vmanagerLaunch: Cadence vManager Session Launcher

  • vAPIUrl
    vManager expose a REST API interface for API. The REST API is a dedicated process for serving remote http requests - vAPI.
    Starting 14.1 s005 The vAPI process is served automatically by the vManager Server process, and as such you need to supply the following url:
    https://[VMANAGER_HOST:VMANAGER_PORT]/vmgr/vapi
    For vmanager 14.1 s002, the vAPI process need to get started manually, as such, the url syntaxt is:
    http://[VAPI_HOST:VAPI_PORT]/vmgr

    • Type: String
  • vAPIUser
    In case of a secure mode, the userId will be shown as the user who perform the operation within vManager tool.
    In case of open mode, the default userid that will be used is "vapi".
    • Type: String
  • vAPIPassword
    In case of a secure mode, a password is needed
    Please contact vManager documentation for further info.
    • Type: String
  • vSIFName
    • Type: String
  • vSIFInputFile
    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 working 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.
    The output of all IDs of the launched sessions can be found at: ${BUILD_NUMBER}.${BUILD_ID}.session_launch.output
    • Type: String
  • credentialInputFile
    Supported only from 16.1 and above.
    vManager can execute jobs in one of two modes:
  • Same user permissions (the account permission where the vManager server is installed) for all jobs launched by the vAPI/Jenkins.
  • Use the Linux account permissions of the actual user who is doing the launch operation.

  • Default (unchecked above) is for the vManager to launch job by using the account permissions where the server is installed.
    When this box is checked, user can choose between using the same credentials used within the authentication section above, or supply a file with user/password in plain text containing only two lines:
    username
    password

    For this (dynamic user/password), a pre-job should place any file into its working directory, and supply the full path to it.
    In case this field is empty, The file name need to be: ${BUILD_NUMBER}.${BUILD_ID}.credential.input, and should be place in the working directory of the current running build.
    Please fill this field only in case you want to hard code the input file name, to be consist across all builds.
  • Type: String
  • deleteInputFile
    • Type: boolean
  • deleteCredentialInputFile
    • Type: boolean
  • useUserOnFarm
    • Type: boolean
  • authRequired
    vManager vAPI can operate in one of two modes:
  • Secured by user/secret key
  • Open
  • In case of a secure mode, the userId (vAPI User) will be shown as the user who perform the operation within vManager tool.
    In case of open mode, the default userid that will be used is "vapi".
  • vsifType
    • Type: String
  • userFarmType
    • Type: String
  • dynamicUserId
    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.
    • Type: boolean
  • advConfig
    • Type: boolean
  • connTimeout
    Connection Timeout is the time (in minutes) for the Jenkins executor to wait till it establish a connection with the vManager server. It is usually very fast, so no need to change the default (1 minute).
    Setting the time to 0 means an unlimited time. In case it is taking too long to establish a connection, and the time passed is more than the Connection Timeout set, the connection to the vManager server will be closed, and the Jenkins executor will be able to continue. The vAPI operation will fail (it will not start), and the build will be marked as failed.
    If no Connection timeout is set, the default is 1 minutes.
    • Type: int
  • readTimeout
    Read Timeout is the time (in minutes) for the Jenkins executor to wait for vManager server to end the current operation. In heavy operations such as collect compact or ranking, the time to response back can vary, and might even take an hour or so depends on the load the vManager server is experiencing.
    Setting the time to 0 means an unlimited time. In case the vAPI call is taking too long, and is more than the Read Timeout set, the connection to the vManager server will be closed, and the Jenkins executor will be able to continue. The vAPI operation will not fail, but the build will be marked as failed.
    If no Read timeout is set, the default is 30 minutes.
    • Type: int
  • envVarible
    • Type: boolean
  • envVaribleFile
    Supported by vManager 15.1 and above only
    In case of a need in adding the vsif environment variables, the pre-job should place into the workspace directory a file with a list of relevant environment variables in json keys format.
    Example:
    "MY_REGRESSION_AREA": "/home/dan/regression",
    "MY_DUT" : "top"
    (Note the comma seperator at the end of each line, to exclude the last line.)
    The input file should be place into the working directory. In case this field is empty, The file name need to be: ${BUILD_NUMBER}.${BUILD_ID}.environment.input
    Please fill this field only in case, you want to hard code the input file name, to be consist across all builds.
    • Type: String
  • inaccessibleResolver
    The following setup allow you to select how the build will behave in each of the state where the session stop from running.

    Continue
    In 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.

    Ignore
    In 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).

    Fail
    In 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 Considerations
    1. 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.
    • Type: String
  • stoppedResolver
    • Type: String
  • failedResolver
    • Type: String
  • doneResolver
    • Type: String
  • suspendedResolver
    • Type: String
  • waitTillSessionEnds
    • Type: boolean
  • stepSessionTimeout
    • Type: int
  • generateJUnitXML
    • Type: boolean
  • extraAttributesForFailures
    • Type: boolean
  • staticAttributeList
    • Type: String
  • markBuildAsFailedIfAllRunFailed
    • Type: boolean
  • failJobIfAllRunFailed
    • Type: boolean
  • envSourceInputFile
    Supported by vManager 17.10 and above only
    In case of a need in adding the vsif environment variables, users can create a list of aliases and store them within a file. The job will 'source' that file prior of reading the vsif.
    Note that this can also serve for any pre stage execution, not just for aliases.
    Relative path is also supported (aka ~/doSomething.sh).
    Script must be in bash.

    The file should be place into a directory with a read permission for the user who launches the regression.
    In case this field is empty, this field is ignored
    • Type: String
  • vMGRBuildArchive
    • Type: boolean
  • deleteAlsoSessionDirectory
    Choosing to delete vManager session during build removal, will trigger an operation during manual/automatic deletion of a build, to deal with the remote session/sessions that were created during that build on the vManager DB.
    When this option is enabled the build will place an instruction file (sdi.properties) within the job directory that specify the sessions to get deleted, as well as other parameters - that will be used during the delete operation.

    Builds that runs while this option is turned off, will not get effected during removal, and will keep their sessions.

    You can choose between two methodologies:

    Sync Delete Methodology (built-in)
    In case you select the sync methodology, the plugin will call vManager vAPI during the build removal process for deleting the sessions that were created during that same build.
    With this option you can also supply a generic user/password to be used for the delete operation, otherwise, the same user that was used during the build will be picked automatically.
    Please note that the sync methodology is lacking two main aspects:
    1. Since Jenkins ignores any exception thrown within the callback functions of RunListener, the build will get deleted even if the session failed to get deleted from vManager DB.
    2. When the vAPI is down, it can take up to 20 seconds to finish the operation (as it needs to wait till vAPI will be available) - the UX at that time, might appear sluggish to the end user.

    Async Delete Methodology (externally)
    In case you want to introduce a more robust approach (promise session deletion even if vManager Server is down, as well as faster UX), you should use the async methodology.
    When Async Methodology is used, the callback function will not try to delete the session, but instead will copy the sdi.properties file into an external location of your choice.
    You should create an additional job, one that is triggered every 1 minute for scanning that directory (and trying to delete the relevant sessions within these sdi files). To exclude the copy of the sdi files during build removal, this flow is not managed by the plugin.
    Please note - defining an external directory location (in windows) requires the use of forward slash instead of backslash.
    • Type: boolean
  • genericCredentialForSessionDelete
    • Type: boolean
  • archiveUser
    • Type: String
  • archivePassword
    • Type: String
  • famMode
    • Type: String
  • famModeLocation
    • Type: String
  • noAppendSeed
    • Type: boolean
  • pipelineNodes
    • Type: boolean
  • masterWorkspaceLocation
    In case of master/nodes setup, in which the job is running on the nodes, the workspace location is of the nodes, not the master.
    The vManager plugins stores run's data at the master location, and as such need to know the full path for the master workspace per build.

    Example:
    (pipelineNodes: true, masterWorkspaceLocation: c:/jenkins/workspace)
    • Type: String

  • Was this page helpful?

    Please submit your feedback about this page through this quick form.

    Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?

        


    See existing feedback here.