You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

What you'll learn

  • How to configure the remote jobs triggering feature
  • How to trigger remote jobs from Test Plans
  • How to configure and validate shipping the test results in Jira

Source-code for this tutorial


Overview

RJT allows users to configure and invoke remote jobs in different CI/CD tools without leaving Xray improving tester performance and streamlining the workflow. 

Most pipelines are triggered by a commit action but sometimes we have the necessity to trigger a remote job to perform some actions, such as:

  • Validate a change in a specific feature
  • Validate a new deployment or new environment
  • Validate new tests on the fly
  • Run automation from Xray Test Plan or Test Execution

The remote job can perform all sort of tasks, including building, deploying the project to an environment, and/or running automated tests.

Most common use is to trigger the execution of automated tests.


In this example we are configuring a Remote Job Trigger for Jenkins that execute Playwright tests and send the execution results back to Xray.

Prerequisites


For this example we will use Jenkins as the CI/CD tool that will execute Playwright tests.


 What you need:

  • Access to a Jenkins instance
  • Xray Enterprise installed in your Jira instance
  • Have a Jenkins job that you can adapt/use to invoke remotely
  • Understand Jenkinsfile


Configure a new RJT for Jenkins in Xray

This example requires configuration in both sides (Xray and Jenkins) so that we can take most advantage of the combination of both tools.

The jenkinsfile will configure a multi-step pipeline that will extract the Playwright test code, execute it and ship the execution results back to Xray.

Configure Jenkins using a jenkinsfile

We use a jenkinsfile to configure the pipeline in Jenkins.

jenkinsfile
pipeline {
  parameters {
    string(name: 'projectKey', defaultValue: '')
    string(name: 'testPlanKey', defaultValue: '')
  }
  agent {
    docker { 
      image 'mcr.microsoft.com/playwright:v1.27.0-focal'
    } 
  }
  stages {
    stage('install playwright') {
      steps {
        sh '''
          npm i -D @playwright/test
          npx playwright install
        '''
      }
    }
    stage('test') {
      steps {
        catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
          sh '''
            PLAYWRIGHT_JUNIT_OUTPUT_NAME=xray-report.xml npx playwright test
          '''
        }
      }
    }
    stage('Import results to Xray') {
      steps {
        step([$class: 'XrayImportBuilder', endpointName: '/junit', importFilePath: 'xray-report.xml', importToSameExecution: 'true', projectKey: params.projectKey, testPlanKey: params.testPlanKey, fixVersion: '1.2', revision: '131', serverInstance: '10be58cc-2776-49a7-be60-b615dc99f4c0'])
      }
    }
    stage('Extract Variable from log'){
      steps {
        script {
          def logContent = Jenkins.getInstance().getItemByFullName(env.JOB_NAME).getBuildByNumber(Integer.parseInt(env.BUILD_NUMBER)).logFile.text
          env.testExecs = (logContent =~ /XRAY_TEST_EXECS:.*/).findAll().first()
          echo testExecs
         }
      }
    }
  }
  post 
  {
    always {
      junit '*.xml'
    }
  }
}


On the above jenkinsfile we are defining two parameters that will be passed when the build is invoked.

jenkinsfile
...
parameters {
    string(name: 'projectKey', defaultValue: '')
    string(name: 'testPlanKey', defaultValue: '')
  }
...


The parameters received can be used in the remaining steps of the pipeline. In order to define what are the parameters we are adding to the pipeline we have added a parameters section with he name of the parameter and a possible default value.

Within the step to run the tests we have added a function to make sure that the next step is performed even if the actual step will fail. This is important because if the tests fail we must assure that the results are sent to Xray.

jenkinsfile-failure
...
catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
...


Using the catchError method we are forcing the step


Once the jenkinsfile is configure in Jenkins it is ready to start to perform the stages and steps defined within it.

We are going to dive into the last part of the jenkinsfile, where we send the results back to Xray, in another section. 

Configure a Remote Jobs Trigger in Xray for Jenkins


Notes:

  • By default it will execute tests for the 3 browser types available (that is why we are forcing it to execute for only one browser)



Integrating with Xray

As we saw in the above example, where we are producing Junit reports with the result of the tests, it is now a matter of importing those results to your Jira instance. You can do this by simply submitting automation results to Xray through the REST API, by using one of the available CI/CD plugins (e.g. for Jenkins) or using the Jira interface to do so.


API

Once you have the report file available you can upload it to Xray through a request to the REST API endpoint for JUnit. To do that, follow the first step in the instructions in v1 or v2 (depending on your usage) to obtain the token we will be using in the subsequent requests.


JUnit XML results

We will use the API request with the definition of some common fields on the Test Execution, such as the target project, project version, etc.

In the first version of the API, the authentication used a login and password (not the token that is used in Cloud).

curl -H "Content-Type: multipart/form-data" -u admin:admin -F "file=@junit.xml" 'http://<LOCAL_JIRA_INSTANCE>/rest/raven/1.0/import/execution/junit?projectKey=COM&testPlanKey=COM-9'

With this command, you will create a new Test Execution in the referred Test Plan with a generic summary and two tests with a summary based on the test name.


On Xray, you can see the tests and you can identify which tests are failing or passing. Below you can see two tests (for valid and invalid credentials):

You can also notice that the summary is now defined based on the files we used for uploading the test results.

Jenkinsfile



Jenkins

As you can see below we are adding a post-build action using the "Xray: Results Import Task" (from the Xray plugin available), where we have some options. For now, we will focus on two of those, one called "Junit XML" (simpler) and another called "Junit XML multipart" (both are explained below and will require two extra files).


Junit XML

  • the Jira instance (where you have your Xray instance installed)
  • the format as "JUnit XML"
  • the test results file we want to import
  • the Project key corresponding of the project in Jira where the results will be imported

Tests implemented using Jest will have a corresponding Test entity in Xray. Once results are uploaded, Test issues corresponding to the Jest tests are auto-provisioned, unless they already exist.


Xray uses a concatenation of the suite name and the test name as the the unique identifier for the test.

In Xray, results are stored in a Test Execution, usually a new one. The Test Execution contains a Test Run per each test that was executed using playwright-test runner.

Detailed results, including logs and exceptions reported during the execution of the test, can be seen on the execution screen details of each Test Run, accessible through the Execution details:


As you can see here:



Tips

  • after results are imported in Jira, Tests can be linked to existing requirements/user stories, so you can track the impact of their coverage.
  • results from multiple builds can be linked to an existing Test Plan in order to facilitate the analysis of test result trends across builds.
  • results can be associated with a Test Environment, in case you want to analyze coverage and test results by that environment later on. A Test Environment can be a testing stage (e.g. dev, staging, preprod, prod) or an identifier of the device/application used to interact with the system (e.g. browser, mobile OS).



References



Jenkinsfile

Create a Test Execution for the test that you have

Fill in the necessary fields and press "Create."

Open the Test Execution and import the JUnit report. 


Choose the results file and press "Import."


The Test Execution is now updated with the test results imported. 

Tests implemented using Jest will have a corresponding Test entity in Xray. Once results are uploaded, Test issues corresponding to the Jest tests are auto-provisioned, unless they already exist.


Xray uses a concatenation of the suite name and the test name as the the unique identifier for the test.

In Xray, results are stored in a Test Execution, usually a new one. The Test Execution contains a Test Run per each test that was executed using playwright-test runner.

Detailed results, including logs and exceptions reported during execution of the test, can be seen on the execution screen details of each Test Run, accessible through the Execution details:


As we can see here:


  • No labels