...
This screen is used to configure the details that it needs to function as expected. There are seven configurations which needs to have values in order for the plugin to read them at runtime and take decisions based on the values provided. The details of each field are as follows,
Event Id of the Jenkins custom event: Custom plugin needs a custom event to be raised whenever when ever we try to trigger the Jenkins job from Jira. This custom event can be created in the in the administration section of Jira. Jira administrator will have to create this custom event, associate it with any notification scheme and make a note of its id. User configuring the plugin can then put this id of the custom event in this configuration textbox
‘Test Execution' issue type Id: This configuration needs the issue type id of the ‘Test Execution’ issue type. We can get this detail from the 'issues’ menu in the administration section.
...
‘Test' issue type id: This configuration needs the issue type id of the 'Test’ issue type. We can get this detail from the 'issues’ menu in the administration section
Id of the custom field which lists the Jenkins Jobs on the issue details screen: Custom plugin also comes with a custom field which is called as ‘Jenkins Job Selector'. Plugin admin needs to add this custom fields to proper screen(Create, Edit and view) in Jira. This field is used to map an already configured Jenkins job to a Xray Test. We will see about how to configure Jenkins job in the custom plugin in the ‘Job Mappings’ screen. In the current configuration we have to give the custom field id of this 'Jenkins Job selector’ field. Please note that we have to append 'customfield_' in front of the actual custom field id while specifying its value in the textbox.
Users of these groups can modify the Jenkins plugin data: Here we can provide the name of the group or groups(comma separated values) members of which can edit the data in different screen of this custom plugin. If this field is left empty then only the Jira administrator can access the details of configuration of the custom plugin and can view its different screens.
Default Jira Integration account to be user for updates: This is a Jira account which is a service account which is required by the plugin to make updates to xray test statuses and to pull attachments to Jira from Jenkins.
Custom field Id of the field which stores link for Xray between Tests and Test Execution: This is a custom field used by Xray to identify Test associated with Test Executions. Please note that we have to append 'customfield_' in front of the actual custom field id while specifying its value in the textbox.
Audit log
This screen shows the logs of different events happening in the plugin at runtime. Please note that these are the events which occur on the Jira side of the plugin. This screen doesn’t capture the details of the events(logs) from Jenkins jobs. Those will be available to the users of the jenkins under the console logs under each run of the job
...
To create a new Jenkins Job which is compatible with the custom Jira plugin we have to create a new 'Freestyle Project'. In order to work properly with Jenkins Jira plugin the Jenkins job would need certain configurations which are specific to the custom plugin that we have built for Jira server. So basically any job can be modified to make it compatible with Jira Jenkins custom plugin as long as it has these configurations as a part of its build steps. These configurations are as follows.
This project is parametrized
...
We need the above three string parameters,
executionIssueKey - To store the issue key of the Xray Test Execution which holds the Xray Test which triggered the current Jenkins Job
testIssueKey - To store the issue key of the test which has triggered the job
testCaseTitle - This holds the summary of the Xray Test Case. This is used as a name for the custom TestComplete reports which will be attached to the Test Execution upon completion of the execution of the Jenkins job
Build Triggers (Trigger build remotely):
This is the place where we specify the auth token which is used in the
...
Job Mapping screen in the custom Jira plugin while configuring the job in Jira
...
Build Steps
The first step should be a windows batch command. This is the first batch command step out of four. The script which runs in this step prepares the job for the execution by pulling the Jira Test and Test Execution related details into the Jenkins build step. This job also pulls in the data sheet if one is attached as an attachment to Jira’s Test Execution. The script is written in node and takes three parameters, name of the Test Execution issue key, full path of the workspace in which the current job will run and the relative path to the workspace root in which the TestComplete scripts expects the data sheet pulled from Jira to exists before the execution of TestComplete starts.
...
The next step should be the TestComplete execution step. Now the configuration for this step can change per TestComplete script but all scripts should pass an additional command line arguments to the TestComplete at run time, This additional command line argument is as follows,
/ExportSummary:"${WORKSPACE}/result.xml"
...
This command line argument generates the xml file in Junit styled reports which holds the result of the TestComplete execution and which can later be pulled into Jira as TestExecution results for each Xray Test. Here “${WORKSPACE}” is a special variable which holds the absolute path to the Jenkins workspace in which the current job is running.
The next step would again be a batch command as follows,
...
This batch command executes a nodejs script which modifies the generated Junit styled xml file and inserts the test case identifier of the Xray Test so that we do not face the issue of duplicate Xray Test creation in Jira while pushing the results back to Jira. This step also pushes the Junit styled reports to Jira’s Test Execution. The parameters taken by this script are execution issue key, test issue key and the full path of the workspace in Jenkins. All three are variables and are replaced by actual values at runtime.
The next step would again be a batch command as follows,
...
This nodejs script zips the custom reports and stores the zipped file at the root of the workspace.
The next step would again be a batch command as follows,
...
This nodejs script zips the custom reports and stores the zipped file at the root of the workspace.
The last step would again be a batch command as follows,
...
This is also a nodejs script which is used to push the custom reports generated by TestComplete and zipped in the previous step to Jira’s Test Execution as an attachment.
Note:
The build steps listed above are expected to be present in the Jenkins job in the same order
Output of the previous build step is feed in as an input to the next one
We can insert steps in between above build steps if need be but those steps should not interfere with the input/output chain generated by the above build steps
Script in each build step writes the log to the console which is visible as a part of console logs under each job run
Script also maintains the logs locally and writes it to the log file on the Jenkins server