SonarQube enables developers to track code quality, which helps them to ascertain if a project is ready to be deployed in production. Further, it allows developers to continuously inspect the code, perform automatic reviews and run analysis to find code quality issues.

Furthermore, SonarQube provides a lot of other features, including the ability to record metrics, evolution graphs etc. It has inherent options to perform automated analysis and continuous integration utilizing tools such as Jenkins, Hudson, etc. In this blog, we will explore the process of creating pipeline scripts for SonarQube integration. Here are the steps.

• Log in to your configuration domain (e.g. https://jenkins.domain.com).
• Go to the specific profile in Jenkins (Here, in this case, it is the root project).
• To configure a Sonar job, select ‘New Item’ available on the left side panel in Jenkins.

• In the subsequent screen provide a job name. Click on ‘Pipeline’ option, if you intend to run a Pipeline, else select the ‘Maven’ option.

• Click on ‘OK’ button to provide configuration details. Now, let us take a look at the various links available on the left side of the screen.
  • Changes – The ‘Changes’ option enables developers to change the name of a job.
  • Build Now – This feature allows developers to run a job in Jenkins. It starts to read the code from the repository and builds the code.
  • Configure – This option enables developers to read the code from the Git/SVN repository.

SonarQube Integration with Jenkins

Here is the complete process of SonarQube integration with Jenkins.

• Click on ‘Configure’ option, which will redirect developers to the following screen, enabling them to read the code from the Git/SVN repository.
• In the General tab, developers can provide a Pipeline name and log build details, such as how many days the logs should be kept etc. In the ‘Days to keep builds’ field, enter the number of days.

• If using a Git repository, select Git project, else proceed to the next tab.
• The next tab is ‘Office 365 Connector’, this screen is used to run a build based on parameters.
• The option ‘This project is parameterized’ is one of the parameters that developers should have a brief idea. It is used to build a job based on branches. In situations, where developers want to run a job based on development/master branches, they can define it using this option else, the job will run as default.

• Build Trigger Section – This option can be utilized, if developers are keen to run the jobs based on specific time intervals e.g. once a day or twice a day. Additionally, jobs can be scheduled to run automatically by using the ‘Build periodically’ option.
• Pipeline Section – The pipeline section is the core feature of a job; it reads data/code from a specific repository in GIT/SVN. However, developers need to specify the script file, which is available in the GIT/SVN application.

• Here is the pipeline script that needs to be added to the Jenkins file.

• Add the following plugin details in the build.gradle/pom.xml file (if it is maven):

a) Sonar Plugin

b) Apply plugin: ‘org.sonarqube’

c) Add SonarQube Server Details:

• Once the configuration is complete, developers can build job manually or automatically. This can be activated using the option ‘Build Now’ available on left side panel of the screen.

• After the build process is complete in Jenkins, it reads the code and compares each line, if it observes any violations of rules, it sends a report to the sonar server. Here is a sample snapshot of the SonarQube report.

Developers can view a list of issues on the SonarQube dashboard. If they are interested to find out what went wrong in their code base, all they have to do it simply click on specific links (numbers above). This action will redirect developers to specific code, where they can fix the issues.

Here is an example, below is a test class, where we have created a sample Java class.

If you observe, Code Smells count is 3, clicking on number 3 will redirect developers to the following screen on a Sonar server. Further, it will show/suggest the vulnerability based on the rule.

In our code ‘testService.java’, we have used a sample system.out .print ln( ) method. In Sonar server, a rule is defined that mentions use logger instead of system.out.

The below method main() is kept empty in ‘my testservice.java class’, as can be observed, SonarQube is recommending to comment on this method since this method is empty. Similarly, it shows other issues in the code. 

Hope this post serves the purpose of providing insights on SonarQube integration, if you have any specific questions or comments, please feel free to post your comments.

The post SonarQube Integration with Jenkins Using Pipelines appeared first on Tech Chronicles.

About Jenkins

Jenkins is an open source software for automation. It is developed in java and is one of the most popular tools for Continuous Integration (CI) and Continuous Delivery (CD).

In 2010, after the acquisition of Sun Microsystems by Oracle, “Hudson” software was in a dispute with its open source community. This dispute became the basis for the launch of the Jenkins project.

Nowadays, “Hudson” (Eclipse public license) and “Jenkins” (MIT license) are two active and independent projects with a very similar purpose.

Jenkins has thousands of plugins you can use in order to speed up the development phase through automation for the entire development life-cycle; build, document, test, package, stage and deployment.

What Does Jenkins Do?

Although the main use of Jenkins could be Continuous Integration (CI) and Continuous Delivery (CD), this open source has a set of functionalities and it can be used without any commitment or dependence from CI or CD, thus Jenkins presents some interesting functionalities to explore:

• Scheduling period jobs (instead of using the traditional crontab)
• Monitoring jobs, its logs and activities by a clean view (as they have an option for grouping)
• Maintenance of jobs could be done easily; assuming Jenkins has a set of options for it
• Setup and scheduling software installation (by using Puppet) in the same host or in another one.
• Publishing reports and sending email notifications

Running PostgreSQL Tasks in Jenkins

There are three common tasks a PostgreSQL developer or database administrator has to do on a daily basis:

1. Scheduling and execution of PostgreSQL scripts
2. Executing a PostgreSQL process composed of three or more scripts
3. Continuous Integration (CI) for PL/pgSQL developments

For the execution of these examples, it is assumed that Jenkins and PostgreSQL (at least the version 9.5) servers are installed and working properly.

Scheduling and Execution of a PostgreSQL Script

In most cases the implementation of daily (or periodically) PostgreSQL scripts for the execution of a usual task such as…

• Generation of backups
• Test the restore of a backup
• Execution of a query for reporting purposes
• Clean up and archiving log files
• Calling a PL/pgSQL procedure to purge tables

t’s defined on crontab:

As the crontab isn’t the best user friendly tool to manage this kind of scheduling, it can be done on Jenkins with the following advantages…

• Very friendly interface to monitor their progress and current status
• The logs are immediately availables and no need any special grant to access them
• The job could be executed manually on Jenkins instead to have a scheduling
• For some kind of jobs, no need to define users and passwords in plain text files as Jenkins do it in a secure way
• The jobs could be defined as an API execution

So, it could be a good solution to migrate the jobs related to PostgreSQL tasks to Jenkins instead of crontab.

On the other hand, most database administrators and developers have strong skills in scripting languages and it would be easy for them to develop small interfaces to deal with these scripts to implement the automated processes with the goal of improving their tasks. But remember, Jenkins most likely already has a set of functions to do it and these functionalities can make life easy for developers who choose to use them.

Thus to define the execution of script it’s necessary to create a new job, selecting the “New Item” option.

Figure 1 – “New Item” in order to define a job to execute a PostgreSQL script

Then, after naming it, choose the type “FreeStyle projects” and click OK.

Figure 2 – Selection of the job (item) type

To finish the creation of this new job, in the section “Build” must be selected the option “Execute script” and in the command line box the path and parameterization of the script that will be executed:

Figure 3 – Specification of the command to execute

For this kind of job, it’s advisable to verify script permissions, because at least execution for the group the file belongs and for everyone must be set.

In this example, the script query.sh has read and execute permissions for everyone, read and execute permissions for the group and read write and execute for the user:

This script has a very simple set of statements, basically only calls to the utility psql in order to execute queries:

Executing a PostgreSQL Process Composed of Three or More Scripts

In this example, I’ll describe what you need to execute three different scripts in order to hide sensitive data and for that, we will follow the below steps…

• Import data from files
• Prepare data to be masked
• Backup of database with data masked

So, to define this new job it’s necessary to select the option “New Item” in the Jenkins main page and then, after to assign a name, the “Pipeline” option must be chosen:

Figure 5 – Pipeline item in Jenkins

Once the job is saved in the “Pipeline” section, on the tab “Advanced project options”, the “Definition” field must be set to “Pipeline script”, as shown below:

Figure 6 – Groovy script in pipeline section

As I mentioned at the beginning of the chapter, the used Groovy script it’s composed by three stages, it means three distinct parts (stages), as presented in the following script:

Groovy is a Java-syntax-compatible object oriented programming language for the Java platform. It’s both a static and dynamic language with features similar to those of Python, Ruby, Perl and Smalltalk.

It’s easy to understand since this kind of script is based in a few statements…

Stage

Means the 3 processes that will be executed: “Import data from files”, “Prepare data to be masked”

and “Backup of database with data masked”.

Step

A “step” (often called a “build step”) is a single task that is part of a sequence. Each stage could be composed of several steps. In this example, the first stage has two steps.

The data are being imported from two distinct sources.

In the previous example, it’s important to note that there are two variables defined at the beginning and with a global scope:

The scripts used in these three steps are calling the psql, pg_restore and pg_dump utilities.

Once the job is defined, it’s time to execute it and for that, it’s only necessary to click the option “Build Now”:

Figure 7 – Execution job

After the build starts it’s possible to verify its progress.

Figure 8 – Starting “Build”

The Pipeline Stage View plugin includes an extended visualization of Pipeline build history on the index page of a flow project under Stage View. This view is built as soon as the tasks are completed and each task is represented by column from the left to the right and it’s possible to view and compare the elapsed time for the serval executions (known as a Build in Jenkins).

Once the execution (also called a Build) finishes, it’s possible to get additional details, clicking on the finished thread (red box).

Figure 9 – Starting “Build”

and then in “Console Output” option.

Figure 10 – Console output

The previous views are extreme utility since they allow to have a perception of the runtime required of each stage.

Pipelines, also known as workflow, it’s a plugin that allows the definition of the application lifecycle and it’s a functionality used in Jenkins for Continuous delivery (CD).vThis plugin was built with requirements for a flexible, extensible and script-based CD workflow capability in mind.

This example is to hide sensitive data but for sure there are many other examples on a daily basis of PostgreSQL database administrator that can be executed on a pipeline job.

Pipeline has been available on Jenkins since version 2.0 and it’s an incredible solution!

Continuous Integration (CI) for PL/pgSQL Developments

The continuous integration for the database development is not as easy as in other programming languages due to the data that can be lost, so it isn’t easy to keep the database in source control and deploy it on a dedicated server particularly once there are scripts that contain DDL (Data Definition Language) and DML (Data Manipulation Language) statements. This is because these kinds of statements modify the current state of the database and unlike other programming languages there is no source code to compile.

On the other hand, there are a set of database statements for which it’s possible the continuous integration as for other programming languages.

This example it’s based only in the development of procedures and it will illustrate the triggering of a set of tests (written in Python) by Jenkins once PostgreSQL scripts, on which are stored the code of the following functions, are committed in a code repository.

Figure 11 – PLpg/SQL functions

These functions are simple and its content only have a few logic or a query in PLpg/SQL or plperlu language as the function f_IsValidEmail:

All the functions presented here do not depend on each other, and then there is no precedence either in its development or in its deployment. Also, as it will be verified ahead, there is no dependence on their validations.

So, in order to execute a set of validation scripts once a commit it’s performed in a code repository it’s necessary the creation of a build job (new item) in Jenkins:

Figure 12 – “Freestyle” project for Continuous Integration

This new build job should be created as “Freestyle” project and in the “Source code repository” section must be defined the repository URL and its credentials (orange box):

Figure 13 – Source code repository

In the section “Build Triggers” the option “GitHub hook trigger for GITScm polling” must be checked:

Figure 14 – “Build triggers” section

Finally, in the “Build” section, the option “Execute Shell” must be selected and in the command box the scripts that will do the validation of the developed functions:

Figure 15 – “Build environment” section

The purpose is to have one validation script for each developed function.

This Python script has a simple set of statements that will call these procedures from a database with some predefined expected results:

This script will test the presented PLpg/SQL or plperlu functions and it will be executed after each commit in the code repository in order to avoid regressions on the developments.

Once this job build is executed, the log executions could be verified.

Figure 16 – “Console Output”

This option presents the final status: SUCCESS or FAILURE, the workspace, the executed files/script, the created temporary files and the error messages (for the failure ones)!

Conclusion

In summary, Jenkins is known as a great tool for Continuous Integration (CI) and Continuous Delivery (CD), however, it can be used for various functionalities like,

• Scheduling tasks
• Execution of scripts
• Monitoring Processes

For all of these purposes on each execution (Build on Jenkins vocabulary) it can be analyzed the logs and elapsed time.

Due to a large number of available plugins it could avoid some developments with a specific aim, probably there is a plugin that does exactly what you’re looking for, it’s just a matter of searching the update center or Manage Jenkins>>Manage Plugins inside the web application.

The post Automating PostgreSQL Daily Tasks Using Jenkins appeared first on Tech Chronicles.

Configuring Jenkins To Build WebGoat

We’re going to scan a known vulnerable webapp, WebGoat, which is an OWASP project used for learning basic web penetration testing skills and vulnerabilities. A good scanner should find a lot of things!

A quick note: We were initially going to use Mutillidae, another vulnerable app written in PHP. However we couldn’t find any good open source PHP Static analyzers that would catch the vulnerabilities.

Anyway, let’s get on with Jenkins. Navigate in your browser to http://localhost:8080 and enter the admin password shown in the terminal running docker. Go ahead and install the default plugins (for a deployed instance, I would recommend only installing plugins you will actually use) and create your first admin user.

WebGoat requires Java 11 to build, which Jenkins won’t install automatically. Head over to the main page -> Manage Jenkins -> Global Tool Configuration. There are two sections here we will update now: JDK installation and Maven installations. We need to add a link to a Java 11 installer – we used https://download.java.net/java/GA/jdk11/13/GPL/openjdk-11.0.1_linux-x64_bin.tar.gz and we can use the default maven. Your config should look like this:

We sometimes see Jenkins have trouble installing a JDK this way if more than one JDK is installed in the system. If this is the first one, there should be no problems.

Finally, we have to set the JAVA_HOME variable. In the Jenkins -> Manage Jenkins -> Configure System menu, enable environment varaibles and set JAVA_HOME equal to /var/jenkins_home/tools/hudson.model.JDK/openjdk11/jdk-11.0.1/.

Now let’s create a pipeline for WebGoat and make sure it builds successfully. Back on the main page choose new item -> freestyle project.

The initial setup is pretty simple:

• Add Webgoat to the various github setting locations (https://github.com/WebGoat/WebGoat/)
• Set the target branch to */develop
• Create a maven build step (“Invoke top level maven targets”) and give it the command “clean install”

Here is the full pipeline configuration:

Try running it and making sure that everything builds successfully.

Adding SonarQube and DependencyCheck

SonarQube setup & security

We already have a SonarQube instance running, we just need to link and configure Jenkins to use it. Log in to http://localhost:9000 and use the default sonarQube login of admin/admin.

Although this is only for practice, I still want to secure our SonarQube instance, so do the following:

• Change the admin password
• Go to administration-> security and turn on “Force user authentication”
• Create a new user for Jenkins.
• Log into the new user, go to the profile -> security section, and generate a token. Copy this for later use.

Finally, create a project named “webgoat” with your jenkins user.

Configure the plugins for Jenkins

We will need two new plugins for jenkins. In the Jenkins home page, go to Mange Jenkins -> Manage Plugins. On the Available tab find and select “OWASP Dependency-Check Plugin” and “SonarQube Scanner for Jenkins”. Install them without restarting.

Back on the Jenkins home, go to Manage Jenkins -> Global Tool Configuration. You should see a new option for SonarQube Scanner. Add an installation here (I just chose the latest from Maven Central) and save.

Finally, head over to Jenkins -> Manage Jenkins -> Configure System and add a sonarqube instance. The URL with our docker container is http://sonarqube:9000 and the token should be the one you saved while setting up the Jenkins user in SonarQube. Here is my setup:

One other thing I had to do to get SonarQube working properly. For some reason I couldn’t completely determine, the SonarQube startup script was truncating the JAVA_HOME path incorrectly, causing errors during the pipeline. To solve this, log into the docker container manually and update the sonar script to the proper JAVA_HOME.

$ docker exec -it secure_pipeline_jenkins_1 bash
jenkins@2ea0acb5905d:/$ cd /var/jenkins_home/tools/hudson.plugins.sonar.SonarRunnerInstallation/sonarqube
jenkins@2ea0acb5905d:~/tools/hudson.plugins.sonar.SonarRunnerInstallation/sonarqube$ head bin/sonar-scanner
#!/bin/sh
#
# SonarQube Scanner Startup Script for Unix
#
# Optional ENV vars:
#   SONAR_SCANNER_OPTS - Parameters passed to the Java VM when running the SonarQube Scanner
#   SONAR_SCANNER_DEBUG_OPTS - Extra parameters passed to the Java VM for debugging
#   JAVA_HOME - Location of Java's installation

JAVA_HOME="/var/jenkins_home/tools/hudson.model.JDK/openjdk11-remote/jdk-11.0.1"

Add SonarQube and DependencyCheck to the pipeline

Now we can add these to our pipeline and start scanning with every build.

In the pipeline created earlier, add two new build steps – Invoke Dependency-Check analysis and Execute SonarQube Scanner. In the SonarQube scanner, add the configuration settings required – the project key and name should match the project you created in SonarQube.

sonar.projectKey=webgoat
sonar.projectName=webgoat
sonar.projectVersion=1.0
sonar.language=java
sonar.java.binaries=**/target/classes
sonar.exclusions=**/*.ts

I am excluding the TypeScript files above since we did not setup Node or a JS build step for our project. In a real project, we would want to ensure that they were also scannable.

In the DependencyCheck advanced section, check to generate HTML reports as well for easier viewing.

Here is my full pipeline configuration now:

Kick off a build and make sure it runs correctly. Afterwards, you should be able to see results.

Viewing Reports

If all runs successfully, logging into SonarQube will show you security scan details (with plenty of findings!) and the pipeline can show you the dependencyCheck results in the workspace -> dependency-check-report.html file.

You can and should at this point consider additional SonarQube plugins (or other SAST tools) that are specifically for your languages and frameworks.

Breaking the Build

We want to know when something isn’t working right at the build phase. SonarQube gives us this for free with the plugin (you should see a nice red ERROR tag under the SonarQube Quality gate) but DependencyCheck requires one more configuration.

Add a post-build check for “Publish Dependency Check Results” and expand the advanced tabs. Just add some threshold data and the build will fail or be marked unstable according to the rules set.

Here  is our final pipeline configuration, fully expanded.

Final Thoughts

Getting a CI/CD pipeline running with some basic security checks can be done within a few minutes. This will help keep your published artifacts in better shape and ensure the team has an opportunity to learn about security issues as soon as they emerge.

The post Creating a Secure Pipeline: Jenkins with SonarQube and DependencyCheck appeared first on Tech Chronicles.

When you have software development projects that you are building and running on Red Hat OpenShift you are probably testing them out locally with Minishift, getting the deployment correct, testing source-to-image or running your Dockerfile builds with environment variables to ensure your CI/CD pipeline is ready to roll. Or maybe you are testing out platforms or containers and kubernetes and you want to get a good developer experience when doing it. You also could be testing out this DevOps thing people have been talking about for years and years.

One other thing to remember is the “Sec” part of DevSecOps: Sec = security. In my case, I use SonarQube locally and on my platform as part of my “Sec” steps to scan my projects and look for errors, vulnerabilities, bad coding practices, and the like. This post is to show how to setup SonarQube via a template within OpenShift (and Minishift) and call it from your Jenkins pipeline.

Setup Minishift

First things first, you need Minishift on your machine. I use a Mac for all my development so I used brew to install the latest Minishift executable. You can see other ways to setup Minishift here. I also use VirtualBox for my virtual machine driver for Minishift. I have a script that runs this for doing all my local Minishift development work that adds the vm-driver for VirtualBox, memory of 10GB, and disk-size of 40GB. I also run with the profile flag and save off the VM under a specific name so I can keep track of it. All personal preferences of course and you can run minishift -h to see the options. Figure out the options you wish to use and run minishift start with those options. It will pull down images, start the system, and give you information on how to log in. When that is up and running we are ready to setup SonarQube.

Minishift Command

Optional: Enable the Admin-User AddOn

This is optional but I like doing this locally. I enable the admin-user addon for Minishift. This lets you log in with ‘god’ rights. You can run minishift addon enable admin-user and then run minishift addon apply admin-user to do this. Once enabled and then applied you can login with admin/admin and see all the inner workings of Minishift and get a glimpse of what OpenShift has under the covers. There are other addons you can see by running the command minishift addons list as well. (Che is the other one I am testing out.)

Setup the SonarQube Project

Now that we have Minishift setup, you can go to the URL that was listed when you started it in the terminal window and login with admin/admin. Click the Create Project button on the top right and enter sonarqube (all lower case) for the Name field and SonarQube for the Display Name field. You can enter a description if you like to ensure you know what it is later when you look at the project listings.

Add the SonarQube project on Minishift

Click the Create button and then click the SonarQube link that is created for you in the project listings. You will get to the blank screen for a Minishift project. From here you can deploy images, import deployment settings (we are doing this one), import other definitions in YAML format as well as select from templates in the catalog. I encourage you to see how you can import other templates, create your own templates for faster deployments, and get more familiar with this interface if you are going the OpenShift way.

I was inspired by the OpenShift Demos GH repo on SonarQube however I needed to update my image and persist data differently. So I went a different route. Not better or worse just different.

Now that you are in the SonarQube project click the “Import YAML / JSON” button and copy and paste this deployment from this GitHub repo. Click the Create button on the bottom right and ensure “Process the Template” is checked. Click Continue to get a listing of parameters. I will go into more detail later on these settings of saving data for the extensions (plugins), logs, temp space as well as the PostgreSQL database space.

You can adjust the space if you wish or just leave the defaults. I usually leave the database password field blank and it generates its own when I am doing local development.

When all is ready click the Create button and then the Close button and you will see a BUNCH of things were created. (Note the default SonarQube login is also admin/admin. If you keep this up you will want to change it OR link in oAuth, GitHub login, or Keycloak.)

What did we just do? Well we create a pod with a PostgreSQL image that when run exposes port 5432 internally to the project. We created a pod with a SonarQube 7.4-community image that when run exposes port 9000 through the https://sonarqube-sonarqube.x.x.x.x route. We have a database connection from SonarQube to PostgreSQL. And we have 5 areas of storage setup to persist data for these containers that are run: database data, SonarQube data, SonarQube extensions/plugins, SonarQube logs, and SonarQube temp space.

Do we need all of these? Maybe not if you want to write into the container and not keep it if it restarts. I do not like doing that. So I do it this way. Feel free to use and adjust to your will.

SonarQube 7.4 Community Edition setup in Minishift

Let’s Dive In!

To get more familiar with what our YAML file actually did we need to explore a little. We setup 2 deployments inside our project, one for each application. One application is SonarQube itself and we are using the image from DockerHub for that. The other application is PostgreSQL and OpenShift comes with that image already. So we just used it. If you click the Applications menu on the left and then Deployments you can see the 2 deployments we have. Click further on the links to see what each one has setup. For each deployment OpenShift will list #1, #2, #3 for the number of the deployment you have running. We just did this so you should see the #1 hyperlinked. Click on it to get something like the below image.

What you can see from the highlighted region are those storage listings, persistent volumes and persistent volume claims in Minishift language. This is telling OpenShift that for those areas of my container running (i.e. /opt/sonarqube/extensions) I want you to save that data in OpenShift to persist it. And as the container comes up or is redeployed mount this path inside the container for reuse. I am simplifying it however that is the gist of what this is doing. You also can see these Mounts going against the Storage listing under the Storage menu on the left. I tried to match the names to have them make sense for you.

Log into SonarQube

Go back to the Overview section of your project and you will see the https://sonarqube-sonarqube.x.x.x listing. This is the Route exposing a URL to the internal SonarQube container running. We only have a route for SonarQube. We do not need an external route for PostgreSQL as only SonarQube has to talk to it. Click that link and log in with admin/admin to ensure you can get to SonarQube. If it starts a tutorial click Skip this tutorial. You should get into SonarQube and see a screen like below. Now get to work!

Use Jenkins in projects to scan code with SonarQube

Having SonarQube is great and all only if you use it. I have an example microservice API project in dotnet core 2.1 that you could put into a brand new project and then use its deployment file to deploy 3 pods: Jenkins, the database, and the API. Then log into Jenkins, approve the OpenShift login, and see how Jenkins works within OpenShift. For SonarQube to work you need to add the SonarQube plugin on the Manage Jenkins → Manage Plugins page and restart. Then go into the Manage Jenkins → Configure System and setup the SonarQube plugin with the name if the server (i.e. SonarQube-Server), the internal-to-Openshift URL (i.e. http://sonarqube.sonarqube.svc), and a generated token from your account page so you can push scan results from the Jenkins process. You also could fork this project linked above and play around to get more familiar. The best way to learn is to do!

The steps on how to use SonarQube with Jenkins are here and are also all over Google.com and StackOverflow.com as well. To use that project linked above you have to load up some Jenkins slave images and update your Jenkinsfile to use them.

Advanced: .NET Core Sonar Scanner Jenkins Slave

There is a .Net Core SonarQube Scanner Jenkins slave image on this other repo that you can import by using the YAML files and importing into the ‘openshift’ project in OpenShift. You can use this project here to create in OpenShift to test it out. The Jenkins slave setup in the Jenkins Configure System screen will need to match the name of the labels in the Jenkinsfile. For now get used to SonarQube and see what you can do!

The post Setup SonarQube in OpenShift for scanning projects via Jenkins appeared first on Tech Chronicles.