This custom action needs to be added at step level in a job to register unit test summary details in ServiceNow.
- credentials (Devops integration token of a GitHub tool created in ServiceNow DevOps or username and password for a ServiceNow devops integration user)
- instance URL for your ServiceNow dev, test, prod, etc. environments
- tool_id of your GitHub tool created in ServiceNow DevOps, required for token based authentication
On GitHub, go in your organization settings or repository settings, click on the Secrets > Actions and create a new secret.
For token based authentication which is available from v3.0.0, create secrets called
SN_INSTANCE_URL
your ServiceNow instance URL, for example https://test.service-now.comSN_DEVOPS_INTEGRATION_TOKEN
required for token based authenticationSN_ORCHESTRATION_TOOL_ID
only the sys_id is required for the GitHub tool created in your ServiceNow instance,required for token based authenticationSN_ORCHESTRATION_TOOL_ID
only the sys_id is required for the GitHub tool created in your ServiceNow instance
For basic authentication , create secrets called
SN_INSTANCE_URL
your ServiceNow instance URL, for example https://test.service-now.comSN_DEVOPS_USER
SN_DEVOPS_PASSWORD
SN_INSTANCE_URL
your ServiceNow instance URL, for example https://test.service-now.comSN_ORCHESTRATION_TOOL_ID
only the sys_id is required for the GitHub tool created in your ServiceNow instance
build:
name: Build
runs-on: ubuntu-latest
steps:
- name: ServiceNow DevOps Unit Test Results
uses: ServiceNow/servicenow-devops-test-report@v3.1.0
with:
devops-integration-token: ${{ secrets.SN_DEVOPS_INTEGRATION_TOKEN }}
instance-url: ${{ secrets.SN_INSTANCE_URL }}
tool-id: ${{ secrets.SN_ORCHESTRATION_TOOL_ID }}
context-github: ${{ toJSON(github) }}
job-name: 'Build'
xml-report-filename: target/surefire-reports/testng-results.xml
build:
name: Build
runs-on: ubuntu-latest
steps:
- name: ServiceNow DevOps Unit Test Results
uses: ServiceNow/servicenow-devops-test-report@v3.1.0
with:
devops-integration-user-name: ${{ secrets.SN_DEVOPS_USER }}
devops-integration-user-password: ${{ secrets.SN_DEVOPS_PASSWORD }}
instance-url: ${{ secrets.SN_INSTANCE_URL }}
tool-id: ${{ secrets.SN_ORCHESTRATION_TOOL_ID }}
context-github: ${{ toJSON(github) }}
job-name: 'Build'
xml-report-filename: target/surefire-reports/testng-results.xml
The values for secrets should be setup in Step 1. Secrets should be created in Step 2. The Step Name should be ServiceNow DevOps Unit Test Results.
Optional DevOps Integration Token of GitHub tool created in ServiceNow instance for token based authentication.
Optional DevOps Integration Username to ServiceNow instance.
Optional DevOps Integration User Password to ServiceNow instance.
Required URL of ServiceNow instance to register the unit test summary details in ServiceNow, for example https://test.service-now.com.
Required Orchestration Tool Id for GitHub created in ServiceNow DevOps.
Required Github context contains information about the workflow run details.
Required Display name of the job given for attribute name in which steps have been added for this custom action. For example, if display name of job is Build then job-name value must be 'Build'
Required The consolidated xml summary report file generated by TestNG framework or directory that contains XML files generated by JUnit framework. The path to directory or xml summary report file should be relative to workspace. The possible values are target/surefire-reports/testng-results.xml for TestNG, target/surefire-reports/ for JUnit, target/surefire-reports/junitreports/ for JUnit when both TestNG and JUnit used in the project specific pom.xml. Note: The value should only contain one (.xml) file if it is a directory path.
For NUnit, XUnit and MSTest test types - path to test(.xml) file should be passed.
No outputs produced.
ServiceNow customers may request support through the Now Support (HI) portal.
Initially, ServiceNow product management and engineering representatives will own governance of these integrations to ensure consistency with roadmap direction. In the longer term, we hope that contributors from customers and our community developers will help to guide prioritization and maintenance of these integrations. At that point, this governance model can be updated to reflect a broader pool of contributors and maintainers.