Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • the web request URL provided above follows this syntax:
    • https://gitlab.com/api/v4/projects/<project_id_in_gitlab>/trigger/pipeline
  • the "Content-Type" header should be "multipart/form-data"
  • the HTTP POST body content, defined in the "Custom data" field, will be used to identify the branch and also the original Test Plan issue key; authentication is done using the "token" variable, created earlier in GitLab

    Code Block
    languagejs
    titlecustom data (i.e. HTTP body content)
    collapsetrue
    token=9e347219182813....&ref=master&variables[TESTPLAN]={{issue.key}}
  • besides, the "Content-Type" header should be "multipart/form-data"


After publishing the rule, you can go to the screen of an issue and trigger a pipeline run in GitLab.

Image Modified



In this case, since the pipeline was configured to report results back to Xray, a new Test Execution would be created and linked back to the source Test Plan where the automation was triggered from.

Tips

Accessing network-restricted CI/CD tools

Azure DevOps

Trigger a Azure DevOps pipeline from a Test Plan and report the results back to it

Azure DevOps configuration

We need to create a service connection, using the "incoming webhook" template, so that we can use Azure DevOps API later on.

Image Added


Create a Personal Access Token (PAT), so you can use it as the password in API requests, along with the "organization name" as username.

Image Added  Image Added



Then, in your Azure DevOps repository containing the project's code and tests, create a pipeline /azure-pipelines.yml; this pipeline will be triggered using Azure DevOps API.


In the following example, the pipeline will receive the Test Plan issue key as an input parameter. It will then run the build, including the automated tests, and in the end it will report the results back to Xray using "curl" utility.

We need to define a resources section, that contains a reference to the webhook configured earlier.


Code Block
languageyml
title/azure-pipelines.yml
parameters:
- name: "testplan"
  type: string
  default: ""

trigger:
- main

resources:
  webhooks:
    - webhook: "MyWebhookTrigger"             ### Webhook alias
      connection: "MyWebhookConnection"       ### Incoming webhook service connection

pool:
  vmImage: ubuntu-latest

steps:

- script: dotnet restore
  displayName: 'install build dependencies'

- script: |
    dotnet test -s nunit.runsettings
  displayName: 'Run tests'
- bash: |
    set -x
    export token=$(curl -H "Content-Type: application/json" -X POST --data "{ \"client_id\": \"$CLIENT_ID\",\"client_secret\": \"$CLIENT_SECRET\" }" "$(xray_endpoint)/api/v2/authenticate"| tr -d '"')  
    curl -o - -H "Content-Type: text/xml" -H "Authorization: Bearer $token" --data @./bin/Debug/net5.0/TestResults/nunit_webdriver_tests.xml  "$(xray_endpoint)/api/v2/import/execution/nunit?projectKey=CALC&testPlanKey=${TESTPLAN}"
  displayName: 'Import results to Xray cloud'


Xray endpoint's base URL and the API key credentials (i.e. client id + client secret) are defined in Azure DevOps as variables. These may be marked as secret.

Image Added  Image Added



Automation configuration

  1. create a new rule and define the "When" (i.e. when it to should be triggered ), to be "Manually triggered"

Image Added

2. define the condition so that this rule can only be executed from Test Plan issue

Image Added

3. define an action (i.e. the "Then") as "Send web request" and configure it as follows

Image Added


  • the web request URL provided above is from Azure DevOps API, for queueing builds, and follows this syntax:
    • https://dev.azure.com/<organization_name>/<project>/_apis/build/builds?ignoreWarnings=true&api-version=6.0
  • authentication is done using the organization name plus the personal access token, created earlier in Azure DevOps, as the login:password pair used to calculate the Base64 content of the Authorization header
  • the "Content-Type" header should be "application/json"
  • the HTTP POST body content, defined in the "Custom data" field, will be used to identify the build definition and also the original Test Plan issue key; 

    Code Block
    languagejs
    titlecustom data (i.e. HTTP body content)
    collapsetrue
    {
        "parameters": "{ \"testplan\": \"{{issue.key}}\" }", 
        "definition":  {
                           "id": 3
                       }
    }
    Expand
    titleHow to find the (build) definition id?

    Note: to find the definition id, you can click on the pipeline in Azure DevOps and its id is shown as part of the URL

    Image Added


After publishing the rule, you can go to the screen of an issue and trigger a pipeline run in Azure DevOps.

Image Added


Image Added


In this case, since the pipeline was configured to report results back to Xray, a new Test Execution would be created and linked back to the source Test Plan where the automation was triggered from.

Image Added

Image Added

TravisCI

Trigger a TravisCI project build from an issue

In this very simple scenario, we'll implement a rule, triggered manually, that will trigger a TravisCI project/job. The action will be available from the "Automation" panel, in all issues of the selected project.

We're assuming that:

  • you just want to trigger a CI job, period; this job may be totally unrelated to the issue from where you triggered it
  • what the CI job will do, including if it will report the results back to Xray or not, is not relevant


TravisCI configuration

In TravisCI, we need to generate an API authentication token for some user, which can be done from the My Account settings page.

Image Added

We have defined the following configuration in our source code that will be used in TravisCI configuration of the pipeline:

Code Block
languageyml
themeDJango
title.travis.yml
sudo: false
language: java
jdk:
  - openjdk8
cache:
  directories:
  - "$HOME/.cache"
  
jobs:
  include:
    - stage: test and report to Xray
      script:
        - |
            echo "building repo..."
            mvn clean compile test --file pom.xml
            export token=$(curl -H "Content-Type: application/json" -X POST --data "{ \"client_id\": \"$CLIENT_ID\",\"client_secret\": \"$CLIENT_SECRET\" }" https://xray.cloud.xpand-it.com/api/v2/authenticate| tr -d '"')
            echo $token
            curl -H "Content-Type: text/xml" -H "Authorization: Bearer $token" --data @target/surefire-reports/TEST-com.xpand.java.CalcTest.xml  "https://xray.cloud.xpand-it.com/api/v2/import/execution/junit?projectKey=$PROJECTKEY"
            echo "done"

For the configuration of the YAML file we used the TravisCI tutorial documentation.

As you can see we are pushing results back to Xray with the last curl command:

Code Block
languageyml
themeDJango
titlecurl command
curl -H "Content-Type: text/xml" -H "Authorization: Bearer $token" --data @target/surefire-reports/TEST-com.xpand.java.CalcTest.xml  "https://xray.cloud.xpand-it.com/api/v2/import/execution/junit?projectKey=$PROJECTKEY"

On this command we are passing the project key in order to report back to a specific Project in the Xray side, we will further ahead show how it is populated.

  • PROJECTKEY - The key that identifies the project on the Jira side.

Once we have the authentication token we followed the TravisCI API documentation to configure the following steps on the Jira side. 

Automation configuration

On the Jira side we will use the Automation capabilities that it provides out of the box, so within the project you want to use automation go to project settings and: 

  1. create a new rule and define the "When" (i.e. when it to should be triggered), to be "Manually triggered"

Image Added

2. define an action (i.e. the "Then") as "Send webhook" and configure it as follows

Image Added


  • the Webhook URL provided above follows this syntax:
    • <TravisCI_API_URL>/repo/{slug|id}/requests (The %2F in the request URL is required so that the owner and repository name in the repository slug are interpreted as a single URL segment.)
  • besides the "Content-Type" header that should be "application/json", define also an "Authorization" header having the value "token <token>", where  you will place the authentication token obtained previously in the TravisCI page and the "Travis-API-Version" header is also mandatory and it will contain the version used.
  • Custom data
    • We included the simplest possible just to trigger the pipeline from the master branch.

After publishing the rule, you can go to the screen of an issue and trigger the Jenkins project/job.

Image Added


In this case, since Jenkins was configured to report results back to Xray, a new Test Execution would be created in Jira/Xray.

Image Added


Trigger a TravisCI project build from a Test Plan and report the results back to it

In this simple scenario, we'll implement a rule, triggered manually, that will trigger a TravisCI project/job. The action will be available from the "Automation" panel, for all Test Plan issues of the selected project.

We're assuming that:

  • you just want to trigger a CI job, period; this job may be totally unrelated to the issue from where you triggered it
  • the results will be submitted back to Xray, if the project is configured to do so in TravisCI


TravisCI configuration

In TravisCI, we need to generate an API authentication token for some user, which can be done from the My Account settings page.

Image Added

Once we have the authentication token we followed the TravisCI API documentation to configure the following steps on the Jira side. 

For the TravisCI the important change we must do is in the YAML file that will configure TravisCI pipeline, we use the following configuration to achieve that:

Code Block
languageyml
themeDJango
title.travis.yml
sudo: false
language: java
jdk:
  - openjdk8
cache:
  directories:
  - "$HOME/.cache"
  
jobs:
  include:
    - stage: test and report to Xray
      script:
        - |
            echo "building repo..."
            mvn clean compile test --file pom.xml
            export token=$(curl -H "Content-Type: application/json" -X POST --data "{ \"client_id\": \"$CLIENT_ID\",\"client_secret\": \"$CLIENT_SECRET\" }" https://xray.cloud.xpand-it.com/api/v2/authenticate| tr -d '"')
            echo $token
            curl -H "Content-Type: text/xml" -H "Authorization: Bearer $token" --data @target/surefire-reports/TEST-com.xpand.java.CalcTest.xml  "https://xray.cloud.xpand-it.com/api/v2/import/execution/junit?projectKey=$PROJECTKEY&testPlanKey=$TESTPLAN"
            echo "done"

For more details about this configuration please check the TravisCI tutorial documentation.

As you can see we are pushing results back to Xray with the last curl command:

Code Block
languageyml
themeDJango
titlecurl command
curl -H "Content-Type: text/xml" -H "Authorization: Bearer $token" --data @target/surefire-reports/TEST-com.xpand.java.CalcTest.xml  "https://xray.cloud.xpand-it.com/api/v2/import/execution/junit?projectKey=$PROJECTKEY&testPlanKey=$TESTPLAN"

On this command we are passing the project key in order to report back to a specific Project in the Xray side, we will further ahead show how it is populated.

  • PROJECTKEY - The key that identifies the project on the Jira side.
  • TESTPLAN - The Test Plan key used to identify the Test Plan to associate the execution with.

Once we have the authentication token we followed the TravisCI API documentation to configure the following steps on the Jira side. 

Automation configuration

On the Jira side we will use the Automation capabilities that it provides out of the box, so within the project you want to use automation go to the automation entry in the project settings and: 

  1. create a new rule and define the "When" (i.e. when it to should be triggered), to be "Manually triggered"

Image Added

2.Define a condition, in our case we  will define that only Test Plan issue types will be allowed to trigger this pipeline, this is achieved with the following condition:

Image Added


3. define an action (i.e. the "Then") as "Send webhook" and configure it as follows

Image Added


  • the Webhook URL provided above follows this syntax:
    • <TravisCI_API_URL>/repo/{slug|id}/requests (The %2F in the request URL is required so that the owner and repository name in the repository slug are interpreted as a single URL segment.)
  • besides the "Content-Type" header that should be "application/json", define also an "Authorization" header having the value "token <token>", where  you will place the authentication token obtained previously in the TravisCI page and the "Travis-API-Version" header is also mandatory and it will contain the version used.
  • Custom data
    • We included the simplest possible just to trigger the pipeline from the master branch.
    • Added environment configuration variables to be used later in the TravisCI pipeline
      • TESTPLAN - that will be automatically filled with the test plan key from where the pipeline is triggered.
      • PROJECTKEY - that will be automatically filled in with the project key.

After publishing the rule, you can go to the screen of an issue and trigger the Jenkins project/job.

Image Added


In this case, since Jenkins was configured to report results back to Xray, a new Test Execution would be created in Jira/Xray.

Image Added

Associated with the Test Plan that we have passed along:

Image Added


Tips

Accessing network-restricted CI/CD tools

If your target system is behind a firewall or it's a local IP address, you can use ngrok tool to create a If your target system is behind a firewall or it's a local IP address, you can use ngrok tool to create a temporary tunnel to it. Please check with your IT/security team(s).

...