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

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 extracts 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.

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.

...
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 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 to assure that the results are sent to Xray.

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

Using the catchError method in case of an error, we are forcing the step to continue the Pipeline execution from the statement following the catchError step.

The behavior of the step when an exception is thrown can be configured to print a message, set a build result other than failure, change the stage result, or ignore certain kinds of exceptions that are used to interrupt the build.

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

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

In order to use the configuration of a RJT in Xray you need to access the Project Settings area and click on the Remote Jobs Trigger option.

This will open the Remote Jobs Trigger configuration page where we can configure remote jobs for Jenkins, Bamboo, GitLab, GitHub and Azure DevOps. You can activate and deactivate the configurations by switching the toggles next to each.

Once you have activated the configuration that you are interested, in our case Jenkins Configuration, click the New Jenkins Configuration to configure your new job. This opens a new form that must filled with proper information.

Fill the Configuration Name and the Job Name with meaningful information that allows you to know what is the purpose of the job just by reading the name.

Next we have the API Token, this can be defined in the Pipeline configuration in Jenkins. Access your project page in Jenkins and scroll down to the Build Triggers area.

The Authentication Token defined in Jenkins must be the same defined in Xray API Token of the Remote Jobs Trigger configuration, in our case 'MyToken'.

In the Username field define the name of the user with proper permissions to invoke the Jenkins Job. Make sure it has the right permissions in Jenkins or the job will return an authentication error when used.

Fill the API URL with the endpoint of your Jenkins instance and in the Password field put the password used by the user identified by the Username above.

Finally we have reached the last configuration fields available: Parameters (Optional), that is a list of key/value pairs that you have defined in you Jenkins pipeline and want to pass from Xray.

You can define static ones or you can use dynamic filled fields available in Xray (more info here). In our case we want to pass the Project key and the Test Plan key so that we can use them when shipping the execution results back to Xray.

For that we use the following options available from Xray:

• ${PROJECT_KEY} that will be filled with the key of the project from where the job is called.
• ${ISSUE_KEY} that will be filled with the issue key, in our case the Test Plan key, from where the job was started from.

The configuration with all the fields filled will look like this:

Once done click the Save button and activate the configuration by switching the Status toggle to on:

Trigger

Once the configuration is done and active you can navigate to the Test Plan from where you want to trigger the job, there you will see that a new button is available to trigger the job you just have configured.

When you choose to call the Remote Jobs Trigger job a new confirmation window will appear with the status of the invocation, either success or failure.

Send results back to Xray

In the above example we have defined a job in another tool and invoked it from Xray. This job will execute the Playwright tests and generate a Junit report.

Now we need to have those results back into Xray for full visibility. The following section will show you two ways you can use to have those results shipped back into Xray.

pipeline {
  parameters {
    string(name: 'projectKey', defaultValue: '')
    string(name: 'testPlanKey', defaultValue: '')
  }
...
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'])
      }
    }
...

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'

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

• https://playwright.dev/docs/test-intro/
• https://playwright.dev/