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:
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.
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.
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.
Details on how to install python3, pip3, and docker
Follow the instruction to add new global credentials to your Jenkins instance:
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:
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.