End-to-End Code Quality Automation: SonarQube in Jenkins with JIRA Ticketing and AWS SSO Integration

In modern software development, code quality assurance is no longer optional — it’s a foundational requirement. Delivery teams usually want three things when it comes to code quality:

1. Consistency – rules should apply equally across all services.
2. Governance – changes to quality standards must be visible and auditable.
3. Zero manual toil – automation should handle checks, reporting, and enforcement.

This blog shows how to achieve all three by wiring SonarQube into Jenkins, driving Quality Gates from service property files, auto-opening JIRA tickets when thresholds are loosened, and securing SonarQube with AWS SSO (SAML).

Objectives

By the end of this guide, you’ll understand how to:

• Integrate SonarQube with Jenkins CI/CD pipelines.
• Create Sonar projects and Quality Gates dynamically.
• Use service-specific property files to define thresholds.
• Run SonarQube analysis inside pipelines.
• Automatically create JIRA tickets if standards are weakened.
• Secure SonarQube with AWS SSO for enterprise-ready access management.

1. Integrating SonarQube with Jenkins

The first step is to bring code quality scanning into your CI/CD pipeline. Jenkins already runs builds, tests, and deployments — adding SonarQube into the flow ensures every build is analyzed.

Configure Jenkins with SonarQube

1. Install the SonarQube Scanner plugin in Jenkins.
2. Navigate to Manage Jenkins → Configure System and add:

• SonarQube server URL
• Authentication Token (generate in SonarQube under your account settings)

3. Add a SonarQube Scanner under Global Tool Configuration.

Once configured, simply add a withSonarQubeEnv stage in your pipeline.

2. Creating Projects and Quality Gates Dynamically

In most organizations, there are dozens (sometimes hundreds) of repositories. Manually creating a Sonar project and assigning a Quality Gate for each repo is error-prone.

Instead, we can automate this:

• Every Jenkins job creates a matching Sonar project.
• A Quality Gate is automatically created with the same name.
• The pipeline attaches the gate to the project.

Use SonarQube Web APIs to create the project, create a gate with the same name, and attach it to the project. Doing this on every run is fine as long as you write idempotent calls.

Example :

# Create (no-op if exists; handle 4xx gracefully in script):

curl -u “$SONAR_TOKEN:” -X POST “$SONAR_URL/api/projects/create” -d “project=${serviceName}” -d “name=${serviceName}”

# Create Quality Gate (handle “already exists”):

curl -u “$SONAR_TOKEN:” -X POST “$SONAR_URL/api/qualitygates/create” -d “name=${serviceName}”

# Attach gate to project:

curl -u “$SONAR_TOKEN:” -X POST “$SONAR_URL/api/qualitygates/select” -d “gateName=${serviceName}” -d “projectKey=${serviceName}”

We can create a single function for executing above API’s which does exactly this: create project → create gate → select gate → then call the reconciliation logic below.This way, developers don’t need to raise tickets or request access — new services get onboarded to SonarQube automatically.

Benefit: Standardization. Every project follows the same onboarding process, leaving no gaps.

3. Property-Driven Quality Gates

One common problem is that quality gates are often hard-coded or manually adjusted in the SonarQube UI. This leads to drift: one service has stricter standards, another has weaker ones, and nobody knows why.

The fix? Use a service property file that declares thresholds in plain text:

# qa-service-ordering-managemnet.properties (example):

qualitygate.bugs = threshold:0, operator:GT

qualitygate.vulnerabilities = threshold:0, operator:GT

qualitygate.code_smells = threshold:50, operator:GT

qualitygate.coverage = threshold:80, operator:LT

Rules:

1. We can use the key to start with qualitygate.
2. Values follow threshold:<number>, operator:<GT|LT|EQ>.

• For “must be at least 80% coverage” use operator:LT with threshold:80 (fail if actual is less than 80 → “error when LT 80”).
• For “no more than 0 critical issues” use operator:GT with threshold:0 (fail if actual is greater than 0).

Defaulting behavior: If a service-specific file is missing or malformed, load a global default (e.g., default-quality-gate.properties) from your shared library.

Benefit: Developers control their own quality rules transparently, but governance is centralized.

4. Reconcile Gate Conditions from Properties (the Important Part)

Your reconciliation function logic enforces governance:

1. Parse the property file into { metric → (threshold, operator) }.
2. Fetch current conditions:

curl -s -u “$SONAR_TOKEN:” “$SONAR_URL/api/qualitygates/show?name=${serviceName}” | jq -c ‘.conditions[]’

3. Delete any existing gate condition whose metric is not in the property file (prevents drift).

4. For each metric:

• If threshold is increased → create JIRA ticket (weakening detected).
• If threshold is same → no action.
• If threshold is stricter → update silently.
• If missing → create it.

With this logic the function will fetche current metric conditions, deletes any metrics not in the property file, and then updates/creates conditions as required. The property file remains the single source of truth for quality rules.

5. Running Sonar Analysis (Maven Example)

Your pipeline stage should run the Sonar Maven plugin and publish JaCoCo XML coverage(if test cases are written by developers otherwise not required):

withSonarQubeEnv(‘sonar’) {
sh “””
mvn -f pom.xml org.sonarsource.scanner.maven:sonar-maven-plugin:${env.SONAR_MAVEN_PLUGIN_VERSION}:sonar -Dsonar.projectKey=”${projectKey}” -Dsonar.projectName=”${projectKey}” -Dsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml
“””
}

Benefit: Code that doesn’t meet agreed standards never reaches production.

6. Security & Secrets

Because Jenkins pipelines handle tokens and credentials:

–> Use Jenkins Credentials for:

• SONAR_TOKEN
• JIRA_USERNAME / JIRA_TOKEN

–> Parameterize SONAR_URL, JIRA_URL, JIRA_PROJECT_KEY, and default property file names via a shared library properties file
Benefit: Security is enforced by design, not left to developers.

7.Auto-Creating JIRA Tickets Only When Standards Are Weakened

The above logic creates a JIRA ticket only when a threshold increases (i.e., when quality is being relaxed). That’s the right governance move.

Implementation points you nailed (and you should keep):

• Issue summary and description clearly state the metric and the change (old → new).
• Map environment (branch/type) into a custom field if you have one (e.g., “QA”, “STAGE”, “PRD”).
• After creating, add the ticket to the active sprint (optional) by fetching the current sprint from a board and posting the issue into it.
• Parameterize JIRA project key, board ID, and custom field IDs via a shared properties file.

Jira Ticket

Integrating SonarQube with AWS SSO

As enterprises grow, managing user access becomes critical. Integrate SonarQube with AWS IAM Identity Center (SSO) via SAML.

1. Prerequisites

• AWS IAM Identity Center set up:

On AWS IAM Identity Center:

1. Create a new SAML application for SonarQube.
2. Set the ACS (Assertion Consumer Service) URL and Entity ID to what SonarQube expects (from SonarQube’s SAML config or metadata).
3. Assign users/groups and download the IdP metadata or note the SSO URL and certificate.

• Custom SAML app created for SonarQube

2. Configure SonarQube for SAML

On SonarQube (sonar.properties or UI if using SAML plugin):

Edit sonar.properties:

sonar.auth.saml.enabled=true

sonar.auth.saml.providerName=AWS-SSO

sonar.auth.saml.loginUrl=https://your-idp.awsapps.com/start

sonar.auth.saml.certificate.secured=[certificate]

sonar.auth.saml.user.login=NameID

sonar.auth.saml.user.name=Attribute

sonar.auth.saml.user.email=Attribute

3. Configure AWS IAM Identity Center

• Create a new application
• Upload SonarQube metadata (or manually configure ACS/Entity ID)
• Assign users/groups
• Download the SAML metadata file for SonarQube

SonarQube LogIn Page

Conclusion

With a few disciplined patterns—consistent naming, property-driven gates, idempotent APIs, and governance on threshold raises—you turn SonarQube from a dashboard into a control system. Jenkins executes; SonarQube evaluates; the property file declares policy; and JIRA provides the change log whenever someone tries to loosen standards.

Add AWS SSO on top, and you’ve got frictionless, compliant access that scales with your org.