<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sonarqube on Daffa Abhipraya</title><link>https://blog.abhipraya.dev/tags/sonarqube/</link><description>Recent content in Sonarqube on Daffa Abhipraya</description><generator>Hugo</generator><language>en-us</language><copyright>© Daffa Abhipraya</copyright><lastBuildDate>Wed, 15 Apr 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://blog.abhipraya.dev/tags/sonarqube/index.xml" rel="self" type="application/rss+xml"/><item><title>PPL: Quality as a Feedback Loop [Sprint 2, Week 3]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w3-code-quality/</link><pubDate>Wed, 15 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w3-code-quality/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>Two weeks of quality infrastructure: wiring in the tools that measure test quality (week 1), then shortening the feedback loop so that signal actually influences the code being written (week 2). Starting state: 91% line coverage, no mutation testing, integration test coverage missing from SonarQube. Ending state: combined unit + integration coverage in SonarQube, mutmut + Stryker running per-MR with results in the CI comment, API mutation score 80.3%.&lt;/p></description></item><item><title>PPL: Quality Gates That Actually Block Bad Code</title><link>https://blog.abhipraya.dev/ppl/part-a/qa/</link><pubDate>Thu, 09 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/qa/</guid><description>&lt;p>Quality tools are useless if they are not enforced. Our project had SonarQube analyzing every commit, schema fuzzing running against our API, and load tests measuring latency, but every single one of them was set to &lt;code>allow_failure: true&lt;/code>. Violations were silently ignored, real bugs slipped through, and nobody noticed because the pipeline was always green. This blog covers how we turned those advisory checks into blocking gates, built automated CI reporting so reviewers could actually see the results, and watched the tools catch a JWT vulnerability, a production crash, and 31 code quality violations that had been accumulating for weeks.&lt;/p></description></item><item><title>PPL: Code Quality [Sprint 2, Week 2]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w2-code-quality/</link><pubDate>Mon, 30 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w2-code-quality/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week I overhauled the CI quality feedback loop with four related MRs. Before this week, quality checks existed but results had to be hunted down manually in GitLab&amp;rsquo;s CI panel. After this week, every MR automatically receives quality reports as inline comments, and the SonarQube gate blocks merges that would lower the quality standard.&lt;/p>
&lt;hr>
&lt;h2 id="sonarqube-quality-gate-in-mr-comments">
 &lt;a class="anchor" href="#sonarqube-quality-gate-in-mr-comments" data-anchor="sonarqube-quality-gate-in-mr-comments" aria-hidden="true">#&lt;/a>
 SonarQube Quality Gate in MR Comments
&lt;/h2>
&lt;p>MR !132 (SIRA-231) added a &lt;code>sonar-scan&lt;/code> post-processing step that fetches the quality gate result from SonarQube and posts it directly as an MR comment via the GitLab API.&lt;/p></description></item><item><title>PPL: Fixing a JWT Vulnerability [Sprint 2, Week 1]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w1-security/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w1-security/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week I addressed a critical security vulnerability flagged by SonarQube and hardened the CI pipeline so security issues block merges instead of being silently reported.&lt;/p>
&lt;h2 id="the-jwt-vulnerability-sonarqube-s5659">
 &lt;a class="anchor" href="#the-jwt-vulnerability-sonarqube-s5659" data-anchor="the-jwt-vulnerability-sonarqube-s5659" aria-hidden="true">#&lt;/a>
 The JWT Vulnerability (SonarQube S5659)
&lt;/h2>
&lt;p>SonarQube flagged &lt;code>dependencies.py:34&lt;/code> as a &lt;strong>CRITICAL vulnerability&lt;/strong>: &lt;code>jwt.get_unverified_header()&lt;/code> reads the JWT header without verifying the signature. This enables the &lt;strong>alg:none attack&lt;/strong>, where an attacker crafts a token with &lt;code>&amp;quot;alg&amp;quot;: &amp;quot;none&amp;quot;&lt;/code> in the header, causing the library to skip signature verification entirely.&lt;/p></description></item><item><title>PPL: From 31 Violations to Zero [Sprint 2, Week 1]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w1-code-quality/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w1-code-quality/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week I enforced strict quality gates across the entire CI pipeline. The project previously had &lt;code>allow_failure: true&lt;/code> on SonarQube and security scans, meaning violations were reported but never blocked merges. I changed that.&lt;/p>
&lt;h2 id="sonarqube-31-violations--0">
 &lt;a class="anchor" href="#sonarqube-31-violations--0" data-anchor="sonarqube-31-violations--0" aria-hidden="true">#&lt;/a>
 SonarQube: 31 Violations → 0
&lt;/h2>
&lt;h3 id="the-violations">
 &lt;a class="anchor" href="#the-violations" data-anchor="the-violations" aria-hidden="true">#&lt;/a>
 The Violations
&lt;/h3>
&lt;p>SonarQube flagged 31 issues across the codebase:&lt;/p>
&lt;ul>
&lt;li>&lt;strong>1 CRITICAL vulnerability&lt;/strong>: &lt;code>jwt.get_unverified_header()&lt;/code> reading JWT headers without signature verification&lt;/li>
&lt;li>&lt;strong>3 CRITICAL code smells&lt;/strong>: duplicated string literals, nested component definitions&lt;/li>
&lt;li>&lt;strong>27 other issues&lt;/strong>: unused variables, missing &lt;code>Readonly&amp;lt;&amp;gt;&lt;/code> on props, duplicate CSS blocks, array index keys&lt;/li>
&lt;/ul>
&lt;h3 id="the-fixes">
 &lt;a class="anchor" href="#the-fixes" data-anchor="the-fixes" aria-hidden="true">#&lt;/a>
 The Fixes
&lt;/h3>
&lt;p>&lt;strong>Backend&lt;/strong> (3 files): Refactored JWT decode to try HS256 first and fall back to asymmetric on &lt;code>DecodeError&lt;/code>, eliminating the unverified header call entirely. Extracted duplicated literals to constants.&lt;/p></description></item><item><title>PPL: Ticket Quality as Code Review [Sprint 2, Week 1]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w1-code-review/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w1-code-review/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week&amp;rsquo;s review work had two dimensions: reviewing the &lt;strong>ticket board&lt;/strong> for sync issues (a form of &amp;ldquo;code review&amp;rdquo; for project management), and letting &lt;strong>SonarQube quality gates&lt;/strong> act as automated code review for the monitoring MR.&lt;/p>
&lt;h2 id="ticket-board-audit">
 &lt;a class="anchor" href="#ticket-board-audit" data-anchor="ticket-board-audit" aria-hidden="true">#&lt;/a>
 Ticket Board Audit
&lt;/h2>
&lt;p>After creating 64 new tickets, I audited all 150+ active tickets (Backlog, Todo, In Progress, In Review) for contradictions and stale data. This is essentially code review applied to project planning.&lt;/p></description></item><item><title>PPL: When 91% Test Coverage Means Nothing</title><link>https://blog.abhipraya.dev/ppl/part-a/tdd-and-qa/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/tdd-and-qa/</guid><description>&lt;p>We had 91% line coverage and felt good about it. Then we ran mutation testing and scored 0%. Every line of our service layer was executed by tests; almost nothing was actually verified. This is the story of how six advanced testing tools exposed the gap between &amp;ldquo;code was run&amp;rdquo; and &amp;ldquo;code was checked,&amp;rdquo; and what that means for any team relying on coverage as a quality signal.&lt;/p>
&lt;blockquote>
&lt;p>&lt;strong>Note:&lt;/strong> Our project is hosted on an internal GitLab instance, so we use the term &lt;strong>MR (Merge Request)&lt;/strong> throughout this blog. If you&amp;rsquo;re coming from GitHub, MRs are the equivalent of &lt;strong>Pull Requests (PRs)&lt;/strong>.&lt;/p></description></item><item><title>PPL: Code Quality [Sprint 1, Week 3]</title><link>https://blog.abhipraya.dev/ppl/part-b/s1w3-code-quality/</link><pubDate>Fri, 13 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s1w3-code-quality/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week I extended the CI quality pipeline with two significant additions: a &lt;strong>migration dry-run validation job&lt;/strong> that catches invalid SQL before merge (MR !67), and ongoing enforcement of zero SonarQube issues across the codebase. The pre-commit hook stack also proved its value by catching issues during the heavy development push of 14 MRs.&lt;/p>
&lt;h2 id="new-ci-job-migration-dry-run-validation">
 &lt;a class="anchor" href="#new-ci-job-migration-dry-run-validation" data-anchor="new-ci-job-migration-dry-run-validation" aria-hidden="true">#&lt;/a>
 New CI Job: Migration Dry-Run Validation
&lt;/h2>
&lt;p>The most impactful quality improvement this week was adding &lt;code>migrate:check&lt;/code> to the CI pipeline (MR !67, SIRA-98). This job runs &lt;code>supabase db push --dry-run&lt;/code> on every MR pipeline, validating that migration files are syntactically correct and compatible with the remote database before the MR can be merged.&lt;/p></description></item><item><title>PPL: Static Analysis in SIRA [Sprint 1, Week 2]</title><link>https://blog.abhipraya.dev/ppl/part-b/s1w2-code-quality/</link><pubDate>Wed, 04 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s1w2-code-quality/</guid><description>&lt;h2 id="the-tool-stack">
 &lt;a class="anchor" href="#the-tool-stack" data-anchor="the-tool-stack" aria-hidden="true">#&lt;/a>
 The Tool Stack
&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>Layer&lt;/th>
 &lt;th>Tool&lt;/th>
 &lt;th>Scope&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>Frontend lint + format&lt;/td>
 &lt;td>&lt;a href="https://biomejs.dev">Biome&lt;/a>&lt;/td>
 &lt;td>TypeScript/TSX, 40+ enforced rules&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>Frontend dead code&lt;/td>
 &lt;td>&lt;a href="https://knip.dev">Knip&lt;/a>&lt;/td>
 &lt;td>Unused exports, imports, dependencies&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>Frontend types&lt;/td>
 &lt;td>&lt;code>tsc --noEmit&lt;/code>&lt;/td>
 &lt;td>TypeScript type checking&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>Backend lint + format&lt;/td>
 &lt;td>&lt;a href="https://docs.astral.sh/ruff/">Ruff&lt;/a>&lt;/td>
 &lt;td>Python, F401/F841 + style rules&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>Backend types&lt;/td>
 &lt;td>&lt;a href="https://mypy.readthedocs.io">mypy&lt;/a>&lt;/td>
 &lt;td>Python static types, strict mode&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>CI quality gate&lt;/td>
 &lt;td>&lt;a href="https://sonarqube.cs.ui.ac.id">SonarQube&lt;/a>&lt;/td>
 &lt;td>Coverage, code smells, security hotspots&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="pre-commit-hooks-husky">
 &lt;a class="anchor" href="#pre-commit-hooks-husky" data-anchor="pre-commit-hooks-husky" aria-hidden="true">#&lt;/a>
 Pre-commit Hooks (Husky)
&lt;/h2>
&lt;p>Five checks run sequentially on every &lt;code>git commit&lt;/code>. A failure at any step blocks the commit:&lt;/p></description></item></channel></rss>