The codebeamer Jenkins plugin is a community supported product, and is not covered by codebeamer support. For more information on Jenkins, see the Welcome to Jenkins Plugins Project.

How to Setup Plugins

Source Code Repository

Before setting up the plugin, you first have to set up a source code repository in your codeBeamer project by following the steps below:

1. Go into the project you want to connect with Jenkins and click on the "SCM Repositories" tab.
2. Click on "New Repository"
3. Select Git and click on "Configure"
4. Select "Create New Managed Repository"
5. Give the repository an easy-to-remember name, and at the bottom, attach a dump file next to "Load dump file".

Setting Up the xUnit Importer Plugin.

• This plugin publishes xUnit Results into codeBeamer Test-Cases, Test-Sets and Test-Runs thus results and coverage of automized tests are available for Work Items (such as Requirements, Tasks, User-Stories etc.).
• The plugin is available through the jenkins plugin manager.

1. Click on "New Item" on the top left hand side of your Jenkins Dashboard. Give the item a name and select "Freestyle project", click on "OK".
2. Go back to your codeBeamer project, click on "SCM Repositories", select your Git repository, and copy the link in the screenshot below.
   
3. Now go back into Jenkins and after naming the Jenkins Job, paste this URL into the "Repository URL" under "Source Code Management" like so:
   
4. Click on "Add" in the previous screenshot next to Credentials, and select Jenkins. In the popup window, type in your codeBeamer user name and password:
   
5. Further down, click on "Add build step", and select "Invoke Ant", seen in the screenshot below. Type"coverage"
   
   into the "Targets" field under the new build section.
   
6. Click on the "Add post-build action" dropdown and select "codeBeamer xUnit Importer":
7. On the section that pops up, you will have to type in the codeBeamer URL of the project you want to connect with Jenkins, as well as your codeBeamer credentials into Username and Password. Below that, you have to copy the corresponding codeBeamer Tracker IDs into at least the required fields (Test Configuration Item ID, Test Case Tracker ID, Test Run Tracker ID). The other IDs are optional.
   
   This plugin is a post build plugin meaning that it can be used in the "Post-build Actions" section.
   
   The plugin needs mandatory parameters to function:
   • URI: URI of an existing codeBeamer server, either a local or hosted instance (example: https://codebeamer.com/cb/)
   • username: username of the account with sufficient privileges to update the wiki page
   • password: password of the account with sufficient privileges to update the wiki page
   • Tracker Configuration Item ID: We can set a specific tracker for Tracker configurations. Generated Test Runs are going to refere to the given Tracker configuration
   • Test Set Tracker ID: Generated Test Sets are going to take place in the specified tracker
   • Test Case Tracker ID: Generated Test Cases based on the unit test packages are going to take place in the given tracker (optionally as children of the given predefined Test Case)
   • Test Run Tracker ID: Generated Test Runs are going to take place in the given Test Run tracker. Every Test Run will be filled in with the give user and Jenkins Test Result data. If the test is failed the Test Run Result will also be failed.
     
     The following parameters are optional:
     • Test Case Top Node ID: The ID of a tracker Item on a Test Case Tracker. If provided then the created Test Cases will have this node/folder as parent. Warning this setting will override Test Case Tracker ID.
     • Bug Tracker ID: This is the Tracker where Bug reports will be submitted.
     • Number of Bugs to report: If the Bug Tracker is also provided limits the number of bugs submitted to codeBeamer, default value 10.
     • Requirement Tracker ID: This is the Tracker where Jenkins will submit Requirements. Jenkins will create new Requirements with the names of the corresponding Test Cases, and link them to their verifying Test Cases automatically.
     • Requirement Top Node ID: The ID of a tracker Item on a Requirement tracker. If provided then the created Requirements will have this node/folder as parent. Warning this setting will override Requirement Tracker ID.
     • Requirement Depth: If the Requirement Tracker ID is also provided limits the depth of the requirements created.
     • Include Packages: You can include one or multiple packages (separator ; ) in the upload to codeBeamer. If not provided all packages are included by default. example: com.exaple;com.otherpackage
     • Exclude Packages: You can exclude one or multiple test packages (separator ; ) from the upload to codeBeamer. example: com.exaple;com.otherpackage
     • Truncate Package Tree: If provided both the uploaded Tests into both the Test Cases and Requirements tracker will have a truncated tree. example: the test has a structure of com.example.package.mytests the provided value is com.example the test to upload will have a package of package.mytests.
8. Here is where you will find the Test Case Tracker ID as an example (without the hashtag), which you will have to copy into the "Test Case Tracker ID" field in Jenkins:
   
9. The form should look something like this, after you have filled out all the relevant fields:
   

Setting Up the Code Coverage Plugin

• This plugin provides Source Code Coverage information - based on Jacoco, Cobertura and Gcov - as Test-Cases and Test-Runs.
• This plugin is available through the jenkins plugin manager

Continued from previous section:

1. Click on "Add post-build action" in Jenkins again as in Step 6. in the previous section, but this time select "codeBeamer Coverage Plugin" from the dropdown:
2. Follow the steps in the previous section to identify the relevant codeBeamer IDs and fill out the fields for this plugin as well:
   
3. And here is a filled-out example:
   
4. The project build time is about 1 minute after the test cases are created (in the first execution after the post build step is set).
   
   The execution should create new test cases:
   
   
   A coverage report in the main test run should look something like this: