We're here to help
Running Provar tests on Jenkins
There are multiple options available for executing your Provar tests on the Jenkins server.
Option 1: Provar ANT libraries on Jenkins server
You should also read carefully and follow all relevant steps in the Introduction to Test Scheduling.
Setting up continuous integration for your Provar project is always recommended. This will help you schedule test runs, get consistent reporting and allow you to execute test cases on a remote server.
There are a few additional steps to keep in mind for use with your RM tool; this is because these tools will be sending build parameters to customize how the Provar tests are run, which tests are run, etc. You can add any additional build parameters as necessary for your use case.
First, create your new job in Jenkins using the type Freestyle Job and add a few build parameters. In order to add build parameters, you must first check the box This project is parameterized.
These are all recommended build parameters as they will be passed from Salesforce to Jenkins to execute the Provar test cases.
TEST_PLAN should be the name of the test plan that you wish to execute in the Provar test project. You can also use TEST_PATH and specify this as a variable/parameter inside of your build.xml. This part is up to the user, and depends on if you are using Provar Test Plans or not.
ANT_TARGET is the name of the ANT target inside of the build.xml file that is used to execute Provar tests via ANT. This is defaulted to runtests and will likely be unchanged unless you have defined multiple targets. The most common use case for this is parallel/distributed execution.
DEPLOYMENT_ID is the RM tool’s deployment ID that is created to execute the URL callout. The deployment phase will need to be built out externally using a RM tool in your Salesforce org. This can be left as the default for now.
BUILD_FILE will be the relative path name of the build file you wish to execute via ANT. This is defaulted to ANT/build.xml, which is the name of the build.xml file Provar generates in the desktop application. You can change this to match your build file.
Now that all of the build parameters have been added, a proper Source Code Management (SCM) can be configured in this Jenkins job. We will be using Git SCM for this guide.
Adjust your settings to match your Git repository that was setup inside of Provar (referenced in the Application Layer of the Architecture section of your RM Tool’s guide).
The next step will be to add an authentication token that will be used to authenticate when calling the Jenkins job.
You can name this token anything you like, however, it is advised to use a Globally Unique Identifier (GUID) or a randomly generated token name so that it is difficult to guess (for security purposes and so the build is not queued accidentally). Once you set this token, make sure you save the URL that is displayed below the field and the token itself to a local file (using Notepad or any similar software). This URL will be used in a later section of this guide.
The last mandatory section will be to add the build action itself.
Here (and in any field inside of the Jenkins job), the build parameters can be utilized using the following syntax: $PARAMETER_NAME. This is the step to execute your Provar tests using the parameters passed from an external release management tool.
Option 2: Provar on Docker
If you wish to execute your test cases inside of a Docker container, please refer to our Docker guide. It is best to utilize this option for any new Jenkins server setups. This will save both time and maintenance on this server since the Dockerfile is managed by Provar. The last part of the Docker guide has detailed instructions on how to implement this solution in conjunction with Jenkins.