{"id":75852,"date":"2025-09-10T12:09:19","date_gmt":"2025-09-10T06:39:19","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=75852"},"modified":"2026-01-02T18:06:24","modified_gmt":"2026-01-02T12:36:24","slug":"end-to-end-code-quality-automation-sonarqube-in-jenkins-with-jira-ticketing-and-aws-sso-integration","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/end-to-end-code-quality-automation-sonarqube-in-jenkins-with-jira-ticketing-and-aws-sso-integration\/","title":{"rendered":"End-to-End Code Quality Automation: SonarQube in Jenkins with JIRA Ticketing and AWS SSO Integration"},"content":{"rendered":"

In modern software development, code quality assurance is no longer optional \u2014 it\u2019s a foundational requirement. Delivery teams usually want three things when it comes to code quality:<\/p>\n

    \n
  1. Consistency<\/strong> \u2013 rules should apply equally across all services.<\/li>\n
  2. Governance<\/strong> \u2013 changes to quality standards must be visible and auditable.<\/li>\n
  3. Zero manual toil<\/strong>\u00a0\u2013 automation should handle checks, reporting, and enforcement.<\/li>\n<\/ol>\n

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

    Objectives<\/strong><\/h3>\n

    By the end of this guide, you\u2019ll understand how to:<\/p>\n

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

      1. Integrating SonarQube with Jenkins<\/strong><\/p>\n

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

      Configure Jenkins with SonarQube<\/strong><\/p>\n

        \n
      1. Install the SonarQube Scanner plugin in Jenkins.<\/li>\n
      2. Navigate to Manage Jenkins \u2192 Configure System and add:<\/li>\n<\/ol>\n
          \n
        • SonarQube server URL<\/li>\n
        • Authentication Token (generate in SonarQube under your account settings)<\/li>\n<\/ul>\n

          3. Add a SonarQube Scanner under Global Tool Configuration.<\/p>\n

          Once configured, simply add a withSonarQubeEnv<\/strong> stage in your pipeline.<\/p>\n

          2. Creating Projects and Quality Gates Dynamically<\/h3>\n

          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.<\/p>\n

          Instead, we can automate this:<\/p>\n

            \n
          • Every Jenkins job creates a matching Sonar project.<\/li>\n
          • A Quality Gate is automatically created with the same name.<\/li>\n
          • The pipeline attaches the gate to the project.<\/li>\n<\/ul>\n

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

            Example<\/strong> :<\/p>\n

            # Create (no-op if exists; handle 4xx gracefully in script):<\/em><\/p>\n

            curl -u “$SONAR_TOKEN:” -X POST “$SONAR_URL\/api\/projects\/create” -d “project=${serviceName}” -d “name=${serviceName}”<\/strong><\/span><\/p>\n

            # Create Quality Gate (handle \u201calready exists\u201d):<\/em><\/p>\n

            curl -u “$SONAR_TOKEN:” -X POST “$SONAR_URL\/api\/qualitygates\/create” -d “name=${serviceName}”<\/strong><\/span><\/p>\n

            # Attach gate to project:<\/em><\/p>\n

            curl -u “$SONAR_TOKEN:” -X POST “$SONAR_URL\/api\/qualitygates\/select” -d “gateName=${serviceName}” -d “projectKey=${serviceName}”<\/strong><\/span><\/p>\n

            We can create a single function for executing above API\u2019s which does exactly this: create project \u2192 create gate \u2192 select gate \u2192 then call the reconciliation logic below.This way, developers don\u2019t need to raise tickets or request access \u2014 new services get onboarded to SonarQube automatically.<\/p>\n

            Benefit<\/strong>: Standardization. Every project follows the same onboarding process, leaving no gaps.<\/p>\n

            3. Property-Driven Quality Gates<\/h3>\n

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

            The fix? Use a service property file<\/strong> that declares thresholds in plain text:<\/p>\n

            # qa-service-ordering-managemnet.properties (example):<\/p>\n

            qualitygate.bugs = threshold:0, operator:GT<\/strong><\/span><\/p>\n

            qualitygate.vulnerabilities = threshold:0, operator:GT<\/strong><\/span><\/p>\n

            qualitygate.code_smells = threshold:50, operator:GT<\/strong><\/span><\/p>\n

            qualitygate.coverage = threshold:80, operator:LT<\/strong><\/span><\/p>\n

            Rules:<\/strong><\/p>\n

              \n
            1. We can use the key to start with qualitygate<\/strong>.<\/li>\n
            2. Values follow threshold:<number>, operator:<GT|LT|EQ><\/strong>.<\/li>\n<\/ol>\n
                \n
              • For \u201cmust be at least 80% coverage\u201d use operator:LT with threshold:80 (fail if actual is less than<\/strong> 80 \u2192 \u201cerror when LT 80\u201d).<\/li>\n
              • For \u201cno more than 0 critical issues\u201d use operator:GT with threshold:0 (fail if actual is greater than<\/strong> 0).<\/li>\n<\/ul>\n

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

                Benefit:<\/strong> Developers control their own quality rules transparently, but governance is centralized.<\/p>\n

                4. Reconcile Gate Conditions from Properties (the Important Part)<\/h3>\n

                Your reconciliation function logic enforces governance:<\/p>\n

                  \n
                1. Parse the property file into { metric \u2192 (threshold, operator) }.<\/li>\n
                2. Fetch current conditions:<\/li>\n<\/ol>\n

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

                  3. Delete any existing gate condition whose metric is not in the property file (prevents drift).<\/p>\n

                  4. For each metric:<\/p>\n

                    \n
                  • If threshold is increased \u2192 create JIRA ticket (weakening detected).<\/li>\n
                  • If threshold is same \u2192 no action.<\/li>\n
                  • If threshold is stricter \u2192 update silently.<\/li>\n
                  • If missing \u2192 create it.<\/li>\n<\/ul>\n

                    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.<\/p>\n

                    5. Running Sonar Analysis (Maven Example)<\/strong><\/h3>\n

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

                    withSonarQubeEnv(‘sonar’) {<\/strong><\/span>
                    \nsh “””<\/strong><\/span>
                    \nmvn -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<\/strong><\/span>
                    \n“””<\/strong><\/span>
                    \n}<\/strong><\/span><\/p>\n

                    Benefit<\/strong>: Code that doesn\u2019t meet agreed standards never reaches production.<\/p>\n

                    6. Security & Secrets<\/h3>\n

                    Because Jenkins pipelines handle tokens and credentials:<\/p>\n

                    –> Use Jenkins Credentials for:<\/p>\n

                      \n
                    • SONAR_TOKEN<\/span><\/li>\n
                    • JIRA_USERNAME \/ JIRA_TOKEN<\/span><\/li>\n<\/ul>\n

                      –> Parameterize SONAR_URL, JIRA_URL, JIRA_PROJECT_KEY, and default property file names via a shared library properties file
                      \nBenefit<\/strong>: Security is enforced by design, not left to developers.<\/p>\n

                      7.Auto-Creating JIRA Tickets Only When Standards Are Weakened<\/h3>\n

                      The above logic creates a JIRA ticket only when a threshold increases (i.e., when quality is being relaxed). That\u2019s the right governance move.<\/p>\n

                      Implementation points you nailed (and you should keep):<\/p>\n

                        \n
                      • Issue summary<\/strong> and description<\/strong> clearly state the metric and the change (old \u2192 new).<\/li>\n
                      • Map environment (branch\/type) into a custom field if you have one (e.g., \u201cQA\u201d, \u201cSTAGE\u201d, \u201cPRD\u201d).<\/li>\n
                      • After creating, add the ticket to the active sprint<\/strong> (optional) by fetching the current sprint from a board and posting the issue into it.<\/li>\n
                      • Parameterize JIRA project key, board ID, and custom field IDs via a shared properties file.<\/strong><\/li>\n<\/ul>\n
                        \"Jira

                        Jira Ticket<\/p><\/div>\n

                        Integrating SonarQube with AWS SSO<\/h3>\n

                        As enterprises grow, managing user access becomes critical. Integrate SonarQube with AWS IAM Identity Center (SSO) via SAML.<\/p>\n

                        1. Prerequisites<\/p>\n

                          \n
                        • AWS IAM Identity Center set up:<\/li>\n<\/ul>\n

                          On AWS IAM Identity Center:<\/strong><\/p>\n

                            \n
                          1. Create a new SAML application for SonarQube.<\/li>\n
                          2. Set the ACS (Assertion Consumer Service) URL and Entity ID to what SonarQube expects (from SonarQube\u2019s SAML config or metadata).<\/li>\n
                          3. Assign users\/groups and download the IdP metadata or note the SSO URL and certificate.<\/li>\n<\/ol>\n
                              \n
                            • Custom SAML app created for SonarQube<\/li>\n<\/ul>\n

                              2. Configure SonarQube for SAML<\/p>\n

                              On SonarQube (sonar.properties or UI if using SAML plugin):<\/strong><\/p>\n

                              Edit sonar.properties:<\/p>\n

                              sonar.auth.saml.enabled=true<\/span><\/p>\n

                              sonar.auth.saml.providerName=AWS-SSO<\/span><\/p>\n

                              sonar.auth.saml.loginUrl=https:\/\/your-idp.awsapps.com\/start<\/span><\/p>\n

                              sonar.auth.saml.certificate.secured=[certificate]<\/span><\/p>\n

                              sonar.auth.saml.user.login=NameID<\/span><\/p>\n

                              sonar.auth.saml.user.name=Attribute<\/span><\/p>\n

                              sonar.auth.saml.user.email=Attribute<\/span><\/p>\n

                              3. Configure AWS IAM Identity Center<\/p>\n

                                \n
                              • Create a new application<\/li>\n
                              • Upload SonarQube metadata (or manually configure ACS\/Entity ID)<\/li>\n
                              • Assign users\/groups<\/li>\n
                              • Download the SAML metadata file for SonarQube<\/li>\n<\/ul>\n
                                \"SonarQube

                                SonarQube LogIn Page<\/p><\/div>\n

                                Conclusion<\/h3>\n

                                With a few disciplined patterns\u2014consistent naming, property-driven gates, idempotent APIs, and governance on threshold raises\u2014you 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.<\/p>\n

                                Add AWS SSO on top, and you\u2019ve got frictionless, compliant access that scales with your org.<\/p>\n","protected":false},"excerpt":{"rendered":"

                                In modern software development, code quality assurance is no longer optional \u2014 it\u2019s a foundational requirement. Delivery teams usually want three things when it comes to code quality: Consistency \u2013 rules should apply equally across all services. Governance \u2013 changes to quality standards must be visible and auditable. Zero manual toil\u00a0\u2013 automation should handle checks, […]<\/p>\n","protected":false},"author":2053,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":3},"categories":[2348],"tags":[1892,4057,8106],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/75852"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/2053"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=75852"}],"version-history":[{"count":3,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/75852\/revisions"}],"predecessor-version":[{"id":77283,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/75852\/revisions\/77283"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=75852"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=75852"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=75852"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}