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 optimise the automation of your continuous quality and release management with centralised 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:

Success

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

Fail 

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

Repository structure: ServiceNow Studio Integrated Source Code #

The repository structure required for triggering the Build Check is the one created automatically by the ServiceNow Studio IDE.

The structure is also used by ServiceNow official GIT actions linked below.

The ServiceNow Studio IDE (as of today San Diego)  links a scoped or global app to one source control repository.

The application is persisted into the repo by the Studio creating a root folder with the sysid of the Application, and inside the root folder:

1. A folder call update containing all the Application configurations.
2. A file with the Application sysid name and XML extension, containing all the Application metadata.

Which configuration elements are checked automatically from the update folder #

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

SAMPLE GIT ACTION / PIPELINE:

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

name: ServiceNow CI/CD Pipeline with QualityClouds LiveCheck

on:

  pull_request:

  push:

    branches:

      – master

jobs:

  build:

    # 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’}}

    steps:

      – name: Checkout

        uses: actions/checkout@v2

      – name: QualityClouds CI/CD BuildCheck for Servicenow

                  uses: qualityclouds/action-application-scan@1.0.0      
        with:

          token: ${{ secrets.QC_TOKEN }}

          instance_url: ‘https://????.service-now.com‘

          api_url: ‘https://api.qualityclouds.com‘

      – name: Slack Notification

        if: ${{ failure() }}

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

        with:

          channel-id: ‘C010SJZGLR1’  # Slack channel id to post message

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

        env:

          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

      – name: ServiceNow CI/CD Apply Changes

        uses: ServiceNow/sncicd-apply-changes@2.0.0

        env:

          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

        with:

          versionTemplate: 1.1

          versionFormat: template

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

          # incrementBy: X

        env:

          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.

    outputs:

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

Setting up an Azure DevOps pipeline for ServiceNow #

In case of using Azure DevOps as build orchestrator on top of a GitHub repository, the following sample would run quality check of the ServiceNow Application:

Azure DevOps Pipeline Sample
# Starter pipeline # Start with a minimal pipeline that you can customize to build and deploy your code. # Add steps that build, run tests, deploy, and more: # https://aka.ms/yaml trigger: – main pool: vmImage: ubuntu-latest steps: – task: DockerInstaller@0 inputs: dockerVersion: ‘17.09.0-ce’ – script: docker run –user root –network=host -v $BUILD_DIRECTORY:/src/:rw -e QC_API_KEY=$QC_API_KEY -e API_URL=https://services.qualityclouds.com -e REPO_URL=https://github.com/your-repo.git -e diff_mode=1 -e MODE=cloud -e URL_ID= -e BRANCH=master -e OPERATION=PUSH -t qualityclouds/pipeline-servicenow snow-scan displayName: ‘Scan’ env: BUILD_DIRECTORY: $(Agent.BuildDirectory) QC_API_KEY: $(apiKey)

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 Source Control Repositories #

You can invoke Quality Clouds for ServiceNow wrapper located in the Docker Hub library, as a generic container, or as a Bitbucket one.