Build Check for ServiceNow

Build Check for ServiceNow enables you to scan your code against three levels of controls: ServiceNow best practices, industry standards, and Quality Clouds own recommendations. It helps you optimize the automation of your continuous quality and release management with centralized quality gates.

What is Build Check

Build Check is a continuous quality tool which automatically checks your code, and applies specified quality gates before you build and deploy. 

How it works

For every repository event , Build Check Action/Pipeline checks the new code and returns the following results:


The scan has finished, and the Quality Gates are PASSED or not configured. The pipeline continues with the process of building and deploying.


The scan has finished, and the Quality Gates are FAILED. The pipeline stops the process of building and deploying. 

Which configuration elements are checked

The following configuration elements are scanned and checked for issues: 

  • Access Control          
  • Business Rule            
  • Catalog Client Scripts
  • Catalog UI Policy       
  • Catalog UI Policy Action 
  • Client Script            
  • Email Script             
  • Inbound Email Actions
  • Record Producer         
  • Script Action            
  • Script Include          
  • Scripted REST Resource
  • Table Transform Map    
  • Transform Script         
  • UI Action                
  • UI Policy                
  • UI Policy Action     
  • UI Script                
  • Widget                  
  • Widget Angular Provider  
  • Workflow 

Setting up a GIT pipeline

 Just create a new Action and lookup from the GIT marketplace the Quality Clouds Git Action.

This is a sample Action structure to use as a template, which follows the following workflow:

  1. The "on" statement checks the event of the action triggered by the repo, in case of GIT you can check the documentation for all supported hooks. You may also specify the branches you are interested.
  2. The "jobs" contain the build process, and the steps in the sample are:
    1. Name "Checkout": the new files that are affected by the "on" statement event triggered.
    2. Name "QualityClouds CI/CD BuildCheck for Servicenow": run the Quality Check of these files using your credentials and identification.
    3. Name "Slack Notification": in case of Quality Check FAIL we will warn the dev team in their slack channel, and abort the pipeline.
    4. Name "ServiceNow CI/CD Apply Changes": this action applies changes from a remote source control to a specified local application
    5. Name "ServiceNow CI/CD Publish App": this action publishes the specified application and all of its artifacts to the application repository.
  3. The "output" just displays the generated Application version number.


# This is a basic workflow to help you get started with Actions

name: ServiceNow CI/CD Pipeline with QualityClouds LiveCheck





      - master



    # Purpose of this job is to Check the Quality of changes,

    # then Apply Remote Changes for the branch triggering 

    # the pipeline build to the Dev instance, then publish the application to 

    # app repo using the template versioning format. 

    name: Publish from Dev

    runs-on: ubuntu-latest

    # Below line can be used to set conditionals for modifying your pipeline as needed.

    # if: ${{ github.event_name == 'pull_request'}}


      - name: Checkout

        uses: actions/checkout@v2


      - name: QualityClouds CI/CD BuildCheck for Servicenow

        uses: qualityclouds/action-snow-full-scan@0.0.5


          token: ${{ secrets.QC_TOKEN }}

          instance_url: 'https://????'

          api_url: ''


      - name: Slack Notification

        if: ${{ failure() }}

        uses: slackapi/slack-github-action@v1.15.0


          channel-id: 'C010SJZGLR1'  # Slack channel id to post message

          slack-message: 'Application deployment stopped due to Quality Gate FAIL'


          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}


      - name: ServiceNow CI/CD Apply Changes

        uses: ServiceNow/sncicd-apply-changes@2.0.0


          nowUsername: ${{ secrets.SN_USERNAME }}

          nowPassword: ${{ secrets.SN_PASSWORD }}

          nowSourceInstance: ${{ secrets.SN_DEV_INSTANCE }}

          appSysID: ${{ secrets.SN_APP_SYSID }}

      - name: ServiceNow CI/CD Publish App

        id: publish_app

        uses: ServiceNow/sncicd-publish-app@1.0.0


          versionTemplate: 1.1

          versionFormat: template

          # Optional, add +X to version number. Default: 1 

          # incrementBy: X


          snowUsername: ${{ secrets.SN_USERNAME }}

          snowPassword: ${{ secrets.SN_PASSWORD }}

          snowSourceInstance: ${{ secrets.SN_DEV_INSTANCE }}

          appSysID: ${{ secrets.SN_APP_SYSID }}


    # This is required to pass the version number output from Publish App 

    # to the input for Install App in the next job! This is because the jobs 

    # run on different Linux instances, so without this Install App won't know

    # what to install.


      publishversion: ${{ steps.publish_app.outputs.newVersion }}

What you'll need

You need to provide a valid API key (token) to connect the Quality Clouds ruleset against which your code will be checked. To obtain an API key, contact your Quality Clouds admin. If you're an admin, check the Administering API keys article.

Other supported Repositories

You can find the pipeline in the Docker Hub library, as a generic container, as a Bitbucket one.

Last modified on Mar 22, 2022