CI/CD Rules
QMetry Test Management for Jira provides the ability to trigger automation jobs for CI/CD tools from the application to trigger automated testing pipelines with a single click. Testers can save remote CI/CD pipeline jobs and launch the jobs directly from QMetry Test Management for Jira. Testers can select and map a configured rule to a test cycle, then trigger the pipeline job and automate the uploading of the results after the successful execution of the job. This feature enables all testers to participate in test automation and also reduces the overhead of navigating between multiple tools by automating the testing process and reporting results.
You can create and trigger the Automation Rules from the Automation module and the Test Cycle module. Rules added in a space are accessible to all the users of that space.
Note
QMetry Test Management for Jira just facilitates the triggering of builds to the CI/CD tools. The resultant action or outcome of triggering the build, including the import of test results back to the application, is not part of the feature. Though you can import the results back to QMetry Test Management for Jira using multiple methods like Jenkins Plugin, Maven Plugin, and so on, when configured as part of the Job.
Create a CI/CD Rule for Jenkins
You can configure CI/CD Rules in the Automation module and Test Cycle module of QMetry Test Management for Jira. This section describes how to configure the CI/CD Rule from the Automation module. For details about configuring CI/CD Rules from the Test Cycle module, refer to the Create CI/CD Rules from Test Cycle module section.
Note
Permissions required: You must have the CI/CD View and CI/CD Add and Edit permissions to create a rule.
Perform the following steps to create a CI/CD rule:
Go to the Automation module.
Select the CI/CD Rules section.
Click the Create New Rule button.
The New Rule screen opens with the parameter fields on it.
Enter the following parameters to configure an automation job to be triggered in the CI/CD tool and then click Save.
Parameter | Description |
|---|---|
Name | Enter your preferred name of the rule. |
Webhook URL | Enter the Webhook URL. For Jenkins, refer to Jenkins Configuration. |
Query Params and Value | Enter the required Query Param and its value. For example, TestCycleKey, TestCaseFolderId, TestCycleFolerId, and so on. After adding the Query Params and Value, click the Add button after entering Query Params and its Value. The entered details will be displayed below the fields. |
Headers and Value | Enter Headers and values e.g. “Authorization”. For Jenkins, refer to Jenkins Configuration. After entering Headers and Values, click the Add button after entering Header and its Value. The entered details will be displayed below the fields. Mask Value After Saving: By default, the checkbox will be auto-selected if the system detects keywords such as “Authorization,” “Token,” “PAT,” or “API KEY” in the Header name. This smart detection mechanism helps identify critical or sensitive data and automatically protects the known sensitive parameters. Once a parameter is tagged with "Mask Value After Saving," its value will be displayed as asterisks after the creation of the CI/CD Rule. NoteOnce a parameter value is set to be masked, the actual value becomes inaccessible after the initial save. You can only delete or overwrite it, as the system blocks any visibility into the existing secret value. |
HTTP-Method | Select the HTTP method from POST/GET/PUT. For example, the remote build trigger API for Jenkins is “POST”. |
Webhook Body | Select from the options Raw/JSON/None on the drop-down and enter the Webhook Data or request body in the field accordingly. Mask Value After Saving: You can select or deselect the "Mask Value After Saving" checkbox when creating or editing Webhook Data. Once a parameter is tagged with "Mask Value After Saving," its value will be displayed as asterisks after the creation of the CI/CD Rule. NoteOnce a parameter value is set to be masked, the actual value becomes inaccessible after the initial save. You can only delete or overwrite it, as the system blocks any visibility into the existing secret value. |
The following are examples of triggering a build without params, triggering a build with query parameters, and triggering a build with raw parameters.
CI/CD Rule Without Parameters
CI/CD Rule With Query Parameters
CI/CD Rule With RAW Parameters
Once the CI/CD Rule is configured, you can:
Trigger CI/CD Rule from the Automation module
Trigger CI/CD Rule from the Test Cycle module
From Test Cycle detail page
From Test Cycle List View
CI/CD Rule Configuration for Dynamic Test Cycle Parameters
CI/CD rules support dynamically passing test cycle parameters, including both system-defined and custom field values. When a rule is triggered from a test cycle, the system automatically populates the relevant test cycle attributes, ensuring accurate and context-aware automation.
Benefits of Dynamic Test Cycle Parameters
This feature allows you to define webhook data using test cycle parameters. When CI/CD rules trigger webhooks, the system includes dynamically resolved test cycle parameters in the payload.
It allows you to modify existing rules to include the required test cycle parameters.
Dynamic parameter passing keeps your CI/CD process flexible and adaptable. For example, you can execute a test cycle across multiple releases or environments without duplicating or modifying the configuration.
Supported Parameters
CI/CD rules support the dynamic passing of test cycle parameters, including both system-defined fields and custom field values.
The following table lists the parameters supported in the CI/CD rule.
Parameter | Description |
|---|---|
$testcycle.key | The unique identifier key for a specific test cycle |
$testcycle.id | The system-generated identifier (UID) for a test cycle |
$testcycle.projectkey | The project key of the test cycle |
$testcycle.label | The labels that are associated with the test cycle |
$testcycle.component | The components that are associated with the test cycle |
$testcycle.fixversion | The fix version that is linked to the test cycle |
$testcycle.sprint | The sprint that is associated with the test cycle |
$testcycle.plannedstartdate | The planned start date of the test cycle |
$testcycle.plannedenddate | The planned end date of the test cycle |
$testcycle.priority | The priority assigned to the test cycle |
$testcycle.status | The current status of the test cycle |
Add Query Params
Perform the following steps to add query parameters:
Enter the test cycle parameters in the Key field in the Query Params section.
Type $ in the Value field to display the available test cycle parameters, and select the appropriate parameter for the key.
Repeat the same steps to add additional query parameters.
Dynamic Parameters for Custom Fields
CI/CD rules support dynamic test cycle parameters, including custom field values.
For example, a test cycle custom field Approved By is configured in the Custom Fields section under Configuration. This custom field is available as a parameter.
When you type $ in the Value field, the custom fields appear in the list of available test cycle parameters.
Add Webhook Data
You can also define the Webhook Data using parameters.
Perform the following steps to add Webhook data:
Go to the Webhook Data section.
Type $ to display the available test cycle parameters, and then select the applicable parameter for the key.
Repeat these steps to add additional webhook parameters.
Once you trigger the CI/CD rule, the system replaces the webhook data parameters with the corresponding test cycle values. You can modify existing rules to include the required test cycle parameters.
Webhook Data Code Example
The following example illustrates a sample webhook data configuration:
{ "projectId": 16400, "summary": "test case from cycle: $testcycle.key (desc - all parameters)", "description": "KEY = $testcycle.key \n ID = $testcycle.id \n PROJKEY = $testcycle.projectkey \n LABEL = $testcycle.label \n COMPONENT = $testcycle.component \n FIXVERSION = $testcycle.fixversion \n SPRINT = $testcycle.sprint \n STARTDATE = $testcycle.plannedstartdate \n ENDDATE = $testcycle.plannedenddate \n PRIORITY = $testcycle.priority \n STATUS = $testcycle.status", "folderId": 3171 }Trigger CI/CD Rules from Automation Module
You can view the configured CI/CD rules in the CI/CD Rules section of the Automation module.
Note
Permissions required: You must have the CI/CD View and CI/CD Trigger permissions to create a rule.
When a CI/CD rule is triggered from the Automation module with test cycle parameters, the rule does not dynamically pass the parameters and instead sends blank values.
Perform the following steps to trigger a CI/CD rule from the Test Automation module:
Go to the Automation module and select CI/CD Rules.
Click the Trigger icon next to the rule to trigger the Jenkins job.
A success message appears on the screen.
Verify the build status in the CI/CD tool where the job was triggered.
Trigger CI/CD Rule From Test Cycle Module
You can create and trigger CI/CD rules from the Test Cycle module. The details of triggered CI/CD rules are recorded in the Audit Logs tab of the test cycle. When a build is triggered from a test cycle, all related actions are captured in the audit logs, allowing testers to track which CI/CD rule was executed for a specific test cycle.
You can configure CI/CD rules to dynamically pass test cycle parameters. When a CI/CD rule is triggered from a test cycle, the system automatically populates the corresponding test cycle attributes. Refer to Dynamic Parameter Passing to Test Cycles for more information.
Note
Permissions required: You must have the CI/CD View and CI/CD Trigger permissions to create a rule.
Perform the following steps to trigger a CI/CD rule from the Test Cycle module:
Go to the Test Cycle module.
Navigate to the test cycle detail page.
Click the Trigger CI/CD Rule button.
The Select CI/CD Rule pane appears.
If the CI/CD Rule is not configured from the Automation module:If you do not have the CI/CD Rule configured in the Automation module of QTM4J, and you click the Trigger CI/CD Rule from the test case detail page, the Select CI/CD Rule pane appears blank without any records of CI/CD Rule on it. You can create CI/CD Rules from the Test Cycle module.
Create a CI/CD Rule from Test Cycle module
Perform the following steps to create a CI/CD rule from the Test Cycle module:
Go to the Test Cycle module.
Navigate to the test cycle details page.
Click the Trigger CI/CD Rule button.
The Select CI/CD Rule pane appears.
To create a new rule from the Test Cycle module, click the Create New Rule button.
The New Rule screen appears.
Perform the same steps described in the Create a CI/CD Rule for Jenkins section to create a new CI/CD Rule.
Once the rule is added, it is displayed on the Select CI/CD Rule pane of the test cycle detail page.
The same CI/CD Rule is also reflected in the Automation module.
Once the CI/CD Rules are created either in the Automation module or in the Test Cycle module, you can view the summary of the configured rule in the panel.
Expand the row to view more configuration details for the rule.
The configuration details for the rule are displayed on the screen.
You can also make the required changes in the configuration from this screen.
Any changes done in the CI/CD rule configuration here in the Test Cycle module will be synced in the Automation module as well.
Link CI/CD Rule with Test Cycle
Perform the following steps to link the CI/CD Rule with a test cycle:
Go to the Test Cycle module.
Navigate to the test cycle details page.
Click the Trigger CI/CD Rule button.
The Select CI/CD Rule pane appears with the list of rules.
Select the CI/CD Rule that you want to link with the current test cycle.
The linked CI/CD Rule starts displaying on the test cycle details page at the top.
Trigger CI/CD Rule from Test Cycle
To trigger the CI/CD rule, click the rule linked to the test cycle.
The CI/CD Rule name gets replaced with the Success label.
Trigger CI/CD Rule from Test Cycle List View
Once linked with the test cycle, the CI/CD Rule can also be triggered for the test cycle from the list view of the Test Cycle module.
Edit CI/CD Rule from Test Cycle
You can edit the rule configuration details by clicking on the Edit icon for the linked CI/CD Rule on the test cycle detail page. Any changes made in the CI/CD Rule configuration here in the Test Cycle module will be synced in the Automation module as well.
Unlink CI/CD Rule from Test Cycle
To unlink the linked CI/CD Rule, click the Unlink icon (X) for the Rule on the test cycle detail page.
Audit Logs in Test Cycle
When a build is triggered from the test cycle, all the related actions are captured in the Audit Logs. This helps testers track which CI/CD Rule was triggered from a particular test cycle.
Navigate to the test cycle detail page and select the Audit Logs tab.
The Audit Logs tab displays all the actions carried out for the CI/CD Rules linked with the current test cycle.
View Details and History
Once the CI/CD Rule is configured, it displays in the CI/CD Rules section of the Automation module.
To view more details about the rule, click the Key of CI/CD Rule on the screen.
The next screen opens with two tabs on it: Detail and History.
Detail Tab
The Detail tab shows configuration details for that CI/CD Rule. You can also edit/delete details from the screen.
History Tab
The History tab shows the audit logs for the actions performed on the CI/C Rule in Automation module as well as in all the test cycles with which the rule is linked. The details include Triggered At, User, Entity Type, Action, Description and Activity.
When a build is triggered from the test cycle, all the actions related to it are also captured in the History tab. It helps testers to track which CI/CD Rule was triggered from particular which test cycle.
Disable a CI/CD Rule
You can disable the active CI/CD Rule from the Automation module. Once the rule is disabled, it can not be selected for triggering the build to the CI/CD tool from the Automation as well as the Test Cycle module. In the Automation module, the Trigger icon will not appear for the disabled/inactive rule. In the Test Cycle module, an error will be shown when you try to link a disabled/inactive rule with the test cycle.
Perform the following steps to disable a CI/CD rule:
Go to the Automation module.
Open the CI/CD Rules section.
Turn the Status inactive for the rule that you want to disable.
The CI/CD Rule turns disabled or inactive.
Once the rule is disabled, it can not be selected for triggering the build to the CI/CD tool from the Automation as well as Test Cycle module.
Delete a CI/CD Rule
You can delete a CI/CD Rule from the Automation module.
Warning
If the rule is linked with any of the test cycles, then all the references with the associated test cycle will be removed on deletion of the rule.
Perform the following steps to delete a CI/CD rule:
Go to the Automation module.
Open the CI/CD Rules section.
Click the Delete icon for the rule that you want to delete.
The confirmation message appears.
Click Delete to proceed.