For a general overview of what pipelines are and what they are good for, please refer to our previous article on BitBucket pipelines that had a small section on that.
Our environment includes:
What is Jenkins Pipeline?
Jenkins provides 2 separate methods to create and schedule Jobs.
Prior to version 2.x of Jenkins, Freestyle Jobs allowed Job configurations to be configured through the web interface. The created Job configurations were versioned. It allowed developers to move build automations to Source Control Management and scripting language. Freestyle jobs provided flexibility but resulted in complex deployments with build instructions versioned but built in Jenkins UI and were prone to errors and management complexity.
With Jenkins 2.x, the Jenkins team introduced a functionality simply called “Pipeline”. Jenkins Pipeline is a modern automation solution where Jobs are scripted in Groovy and stored in a Jenkinsfile. This provides an extremely powerful and flexible approach to multi-branch build pipelines to configuration as code.
What are Jenkins Scripts?
Jenkins Scripts are a DSL written in Groovy. Jenkins Scripts provide a simplified, declarative syntax on top of the Pipeline subsystem. This allows us to describe a build pipeline in code, maximizing infrastructure as code paradigm while using predefined structured concepts in Jenkins. Groovy is a unique choice of modern language that is easy for Java developers to learn, Java developers being the largest user base of Jenkins users. And Groovy is flexible enough to have a shallow learning curve for experienced developers, and provides a rich feature set, the ability to add Jenkinsfiles to source control, and the opportunity to validate Pipeline syntax before runtime.
Adding configuration file scanning to Jenkins Pipeline
Jenkins is designed to have a coordinator instance which sends the specific job instructions to a set of agents. Each agent may or may not have certain software installed or not. Jenkins allows for a container to be run as an agent as well.
Assumptions
- Docker, Python and PIP3 are installed.
- Agents for Docker, Python and PIP3 are labeled with the simple labels “docker”, “python3” and “pip3”.
- CoGuard login details are stored in the Jenkins Credentials.
Installing Python, PIP3 and Docker
Details on how to install python3, pip3, and docker
Adding CoGuard to Jenkins Credentials
Follow the instruction to add new global credentials to your Jenkins instance:
- We expect you to Add Credentials
- In the Kind field add “username”
- In the Kind field add “password”
- In the ID field label “coguard”
Example: Jenkins Script adding CoGuard configuration scanning
CoGuard CLI accepts a number of command line parameters. We apps these parameters though an environmental variable using Jenkins Script. To limit the CoGuard Vulnerabilities to a Severity of Level 3 and above, we specify an environment variable MINIMUM_FAIL_LEVEL. Full details on the CoGuard Vulnerability levels.
The script can then look like the following:
pipeline {
agent {
label(‘python3 && docker && pip3’)
}
environment {
COGUARD_USER_NAME = credentials('jenkins-coguard-username')
COGUARD_PASSWORD = credentials('jenkins-coguard-password')
}
stages {
stage(‘Build’) {
// YOUR BUILD INSTRUCTIONS TO GET THE DOCKER IMAGE
// THE ASSUMPTION IS THAT THIS PART CREATES A DOCKER IMAGE
// CALLED your-docker-image IN YOUR REPOSITORY WITH THE BUILD_ID AS TAG
}
stage('Test') {
steps {
script {
sh “pip3 install coguard-cli”
sh “coguard --minimum-fail-level=${MINIMUM_FAIL_LEVEL:-3} docker-image your-docker-image:$BUILD_ID”
}
}
}
}
}
This is a simple example. The outputs from CoGuard can be integrated into the JIRA, Slack, email upon failure, etc.
Additional details about using CoGuard in your CI/CD pipeline or in your local environment can be found here.