DEV Community: Younes Ben Tlili

QualityHub v1.2.0 — Your CI now posts quality reports directly on your MRs

Younes Ben Tlili — Wed, 25 Feb 2026 23:56:08 +0000

In my last article, I showed how qualityhub analyze gives you a risk score and go/no-go decision after every test run.
At the end, I mentioned this was coming:

Auto-commenting on MRs — qualityhub analyze --comment posts directly on your GitLab MR or GitHub PR

It's shipped. Here's what it looks like.

The problem with markdown reports
v1.1.0 already had --format markdown. You could generate a quality report and... do whatever you wanted with it. Most people saved it to a file and manually copied it somewhere.
That's one step too many.
The whole point of catching regressions is to surface them at the moment a developer is making a decision — when they're reviewing a merge request. Not buried in a CI log. Not in a separate tool. Right there, on the MR.

What v1.2.0 does
One flag. That's it.

qualityhub analyze --comment

Your CI runs, parses the test results, calculates the risk score, and posts this directly on your GitLab MR or GitHub PR:

The comment is automatically updated on every pipeline run. No duplicate comments piling up on your MR.

Setup: GitLab CI

quality-check:
  stage: test
  script:
    - npm test -- --coverage
    - npx qualityhub-cli parse jest ./coverage
    - npx qualityhub-cli analyze --comment
  cache:
    paths:
      - .qualityhub/   # history persists between runs → regression detection works
  only:
    - merge_requests

Set GITLAB_TOKEN as a CI/CD variable (needs api scope). Everything else — project ID, MR number — is auto-detected from GitLab's environment variables. No extra config.

Setup: GitHub Actions

- name: Run tests
  run: npm test -- --coverage

- name: QualityHub analysis
  run: |
    npx qualityhub-cli parse jest ./coverage
    npx qualityhub-cli analyze --comment
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

GITHUB_TOKEN is already available in every GitHub Actions workflow. Nothing to configure.

All the options
For teams with specific setups:

# Self-hosted GitLab
qualityhub analyze --comment \
  --api-url https://gitlab.yourcompany.com \
  --token $GITLAB_TOKEN

# Explicit project + MR (outside CI)
qualityhub analyze --comment \
  --provider gitlab \
  --token $GITLAB_TOKEN \
  --project-id 123 \
  --mr-id 42

# GitHub
qualityhub analyze --comment \
  --provider github \
  --token $GITHUB_TOKEN \
  --project-id owner/repo \
  --mr-id 42

Why this matters
When a comment appears directly on the MR, it changes the dynamic of code review.
Instead of "tests passed, let's merge", reviewers now see:

The exact risk score
Whether coverage went up or down vs the previous run
Any new test failures introduced by this branch
A clear PROCEED / CAUTION / BLOCK decision

The context is there at the moment the decision is made. Not one click away. Not in another tab. On the MR.
This is what I was trying to build when I started QualityHub: quality intelligence at the right moment.

Try it

npm install -g qualityhub-cli

# Parse your test results
qualityhub parse jest ./coverage

# Post on your MR
qualityhub analyze --comment

GitHub: ybentlili/qualityhub-cli
npm: qualityhub-cli
MIT licensed. If this is useful, a ⭐ on GitHub goes a long way.

Part 3 of building QualityHub in public. Part 1 — Part 2

I built a CLI that tells you if your release is safe to deploy — in 2 seconds

Younes Ben Tlili — Tue, 17 Feb 2026 22:53:38 +0000

Every team has the same moment before deploying:

"Tests passed... coverage looks okay... should we ship it?"

Someone eyeballs the numbers, checks if anything looks off, and says "yeah, let's go." No real process. No history. No way to catch a slow regression creeping in over weeks.
I got tired of that. So I built

qualityhub analyze

What it does
You run your tests. Then:

npx qualityhub-cli parse jest ./coverage
npx qualityhub-cli analyze

You get this:

🔍 QualityHub Analysis
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   Project:  my-app@2.3.1
   Branch:   main

   📊 Tests
      ❌ 243/250 passed (97.2%)
      ❌ 4 failed
      ⏭️  3 skipped
      ⏱️  Duration: 12.7s

   📈 Coverage
      Lines:      █████████████████░░░ 87.3%  ▼ -3.2%
      Branches:   ████████████████░░░░ 82.2%
      Functions:  ██████████████████░░ 91.3%

   🚨 Issues Detected
      🟡 4 tests failed (97.2% pass rate)
      🎲 2 flaky tests detected
      📉 Coverage dropped 3.2% since last run
      🆕 2 new test failures since last run
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   🎯 Risk Score:  ⚠️ 72/100 (MEDIUM RISK)
   📋 Decision:    ⚠️  CAUTION — Review issues before deploying
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A risk score from 0 to 100. A clear decision: PROCEED, CAUTION, or BLOCK. In 2 seconds.

The problem I was solving
At my previous job, we had 20 projects across 5 teams. Quality tracking was done in Excel files. Every sprint, someone would manually collect metrics from each team — test pass rates, coverage percentages, SonarQube results — paste them into a spreadsheet, and email it around.
Nobody caught the slow regressions. Coverage would drop 0.5% per sprint, and after 6 months you'd realize you went from 85% to 70% without anyone noticing.
I wanted something that:

Runs in CI, not in someone's inbox
Compares every run with the previous one automatically
Catches what humans miss: slow drifts, new failures, build slowdowns
Gives a clear answer, not a dashboard you have to interpret

How the scoring works
The risk score starts at 100 and gets penalized:
Test results (40 points max)
Every failed test costs points. 2% failure rate? Small penalty. 10% failure rate? You're blocked.
Coverage (30 points max)
Below 80% line coverage? Penalty. Below 50%? Critical.
Regressions (15 points max)
This is where it gets interesting. The CLI stores history locally in .qualityhub/history.json. On every run, it compares with the last one:

Coverage dropped 3%? Flagged.
2 new test failures? Flagged.
Build time increased 20%? Flagged.

Issue severity (15 points max)
Critical issues (security vulnerabilities, quality gate failures) cost more than warnings.
The final score maps to a decision:

85-100: PROCEED ✅
65-84: CAUTION ⚠️
40-64: HIGH RISK 🔶
0-39: BLOCK 🛑

No server needed
This is the part I'm most proud of. Everything runs locally:

History is stored in .qualityhub/history.json
No account to create
No SaaS to connect
No API keys

Install and run:

npm install -g qualityhub-cli
qualityhub parse jest ./coverage
qualityhub analyze

That's it. Value in 30 seconds.

CI/CD integration
The CLI exits with code 1 when the decision is BLOCK. So you can use it as a quality gate:

# .gitlab-ci.yml
quality-check:
  stage: test
  script:
    - npm test -- --coverage
    - npx qualityhub-cli parse jest ./coverage
    - npx qualityhub-cli analyze
  cache:
    paths:
      - .qualityhub/

The cache persists the history between pipeline runs, so regression detection works across commits.

Markdown reports for merge requests
You can also generate a Markdown report to post on your MR:

qualityhub analyze --format markdown --output report.md

What's next
I'm working on:

Auto-commenting on MRs — qualityhub analyze --comment posts directly on your GitLab MR or GitHub PR
More parsers — pytest, XCTest, Go test
AI-powered insights — Using LLMs to explain why your quality is changing and what to fix first

Try it

npm install -g qualityhub-cli

# Or test with example data:
git clone https://github.com/ybentlili/qualityhub-cli
cd qualityhub-cli
npm install && npm run build && npm link
qualityhub parse jest ./examples/jest
qualityhub analyze

GitHub: ybentlili/qualityhub-cli
npm: qualityhub-cli
It's MIT licensed. Stars, feedback, and contributions are welcome.
If you've ever looked at a CI pipeline and thought "I think we can ship this" — this is for you.

I Built QualityHub: AI-Powered Quality Intelligence for Your Releases

Younes Ben Tlili — Sun, 01 Feb 2026 11:10:45 +0000

🎯 The Problem

As a developer , I faced this question every day:

"Can we ship this release to production?"

We had test results, coverage metrics, SonarQube reports... but no single source of truth to answer this simple question.

So I built QualityHub - an AI-powered platform that analyzes your quality metrics and gives you instant go/no-go decisions.

🚀 What is QualityHub?

QualityHub is an open-source quality intelligence platform that:

📊 Aggregates test results from any framework (Jest, JUnit, JaCoCo...)
🤖 Analyzes quality metrics with AI
✅ Decides if you can ship to production
📈 Tracks trends over time in a beautiful dashboard

The Stack

Backend: TypeScript + Express + PostgreSQL + Redis
Frontend: Next.js 14 + Tailwind CSS
CLI: TypeScript with parsers for Jest, JaCoCo, JUnit
Deployment: Docker Compose (self-hostable)
License: MIT

💡 How It Works

1. Universal Format: `qa-result.json`

Instead of forcing you to use specific tools, QualityHub uses an open standard format:

{
  "version": "1.0.0",
  "project": {
    "name": "my-app",
    "version": "2.3.1",
    "commit": "a3f4d2c",
    "branch": "main",
    "timestamp": "2026-01-31T14:30:00Z"
  },
  "quality": {
    "tests": {
      "total": 1247,
      "passed": 1245,
      "failed": 2,
      "skipped": 0,
      "duration_ms": 45230,
      "flaky_tests": ["UserAuthTest.testTimeout"]
    },
    "coverage": {
      "lines": 87.3,
      "branches": 82.1,
      "functions": 91.2
    }
  }
}

This format works with any test framework.

2. CLI Parsers

The CLI automatically converts your test results:

# Jest (JavaScript/TypeScript)
qualityhub parse jest ./coverage

# JaCoCo (Java)
qualityhub parse jacoco ./target/site/jacoco/jacoco.xml

# JUnit (Java/Kotlin/Python)
qualityhub parse junit ./build/test-results/test

3. Risk Analysis Engine

The backend analyzes your results and calculates a Risk Score (0-100):

// Risk factors analyzed:
- Test pass rate
- Code coverage (lines, branches, functions)
- Flaky tests
- Coverage trends
- Code quality metrics (if available)

Output:

{
  "risk_score": 85,
  "status": "SAFE",
  "decision": "PROCEED",
  "reasoning": "Test pass rate: 99.8%. Coverage: 87.3%. No critical issues.",
  "recommendations": []
}

4. Beautiful Dashboard


![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zx8uj4p9okks9a4ohq7h.png)

Track metrics over time, see trends, and make informed decisions.

🔧 Quick Start

Self-Hosted (5 minutes)

# Clone repo
git clone https://github.com/ybentlili/qualityhub.git
cd qualityhub

# Start everything with Docker
docker-compose up -d

# ✅ Backend: http://localhost:8080
# ✅ Frontend: http://localhost:3000

Use the CLI

# Install
npm install -g qualityhub-cli

# Initialize
qualityhub init

# Parse your test results
qualityhub parse jest ./coverage

# Push to QualityHub
qualityhub push qa-result.json

Done! Your metrics appear in the dashboard instantly.

🎨 Why I Built This

The Pain Points

Fragmented Tools: Jest for tests, JaCoCo for coverage, SonarQube for quality... each tool has its own UI and format.
No Single Answer: "Can we ship?" required checking 5 different tools and making a gut decision.
No History: Hard to track quality trends over time.
Manual Process: No automation, no CI/CD integration.

The Solution

QualityHub aggregates everything into one dashboard and uses AI to make the decision for you.

🏗️ Architecture

┌─────────────┐
│     CLI     │ ← Parse test results
└──────┬──────┘
       │ POST /api/v1/results
       ↓
┌─────────────────────────────┐
│     Backend (API)           │
│  • Express + TypeScript     │
│  • PostgreSQL + Redis       │
│  • Risk Analysis Engine     │
└──────────────┬──────────────┘
               │
               ↓
┌─────────────────────────────┐
│   Frontend (Dashboard)      │
│  • Next.js 14               │
│  • Real-time metrics        │
└─────────────────────────────┘

📊 Technical Deep Dive

1. The Parser Architecture

Each parser extends a base class:

export abstract class BaseParser {
  abstract parse(filePath: string): Promise;

  protected buildBaseResult(adapterName: string) {
    return {
      version: '1.0.0',
      project: {
        name: this.projectInfo.name,
        commit: process.env.GIT_COMMIT || 'unknown',
        // Auto-detect CI/CD environment
        timestamp: new Date().toISOString(),
      },
      metadata: {
        ci_provider: this.detectCIProvider(),
        adapters: [adapterName],
      },
    };
  }
}

This makes adding new parsers trivial. Want pytest support? Extend BaseParser and implement parse().

2. Risk Scoring Algorithm (MVP)

The current version uses rule-based scoring:

let score = 100;

// Test failures
if (tests.failed > 0) {
  score -= tests.failed * 5;
}

// Coverage thresholds
if (coverage.lines < 70) {
  score -= 15;
}

// Flaky tests
if (flakyTests.length > 0) {
  score -= flakyTests.length * 3;
}

// Ensure 0-100 range
score = Math.max(0, Math.min(100, score));

Future: Replace with AI-powered analysis (Claude API) for contextual insights.

3. Database Schema

Simple and efficient:

CREATE TABLE projects (
    id UUID PRIMARY KEY,
    name VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE qa_results (
    id UUID PRIMARY KEY,
    project_id UUID REFERENCES projects(id),
    version VARCHAR(50),
    commit VARCHAR(255),
    branch VARCHAR(255),
    timestamp TIMESTAMP,
    metrics JSONB,  -- Flexible JSON storage
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE risk_analyses (
    id UUID PRIMARY KEY,
    qa_result_id UUID REFERENCES qa_results(id),
    risk_score INTEGER,
    status VARCHAR(50),
    reasoning TEXT,
    risks JSONB,
    recommendations JSONB,
    decision VARCHAR(50)
);

JSONB allows flexible metric storage without schema migrations.

🚀 What's Next?

v1.1 (Planned)

🤖 AI-Powered Analysis with Claude API
📊 Trend Detection (coverage dropping over time)
🔔 Slack/Email Notifications
🔌 GitHub App (comments on PRs)

v1.2 (Future)

📈 Advanced Analytics (benchmarking, predictions)
🔐 SSO & RBAC for enterprise
🌍 Multi-language support
🎨 Custom dashboards

💡 Lessons Learned

1. Open Standards Win

Making qa-result.json an open standard was key. Now anyone can build parsers or integrations.

2. Developer Experience Matters

The CLI must be dead simple:

qualityhub parse jest ./coverage  # Just works

No config files, no setup, just works.

3. Self-Hosting is a Feature

Many companies can't send their metrics to external SaaS. Docker Compose makes self-hosting trivial.

🤝 Contributing

QualityHub is 100% open-source (MIT License).

Want to contribute?

🧪 Add parsers (pytest, XCTest, Rust...)
🎨 Improve the dashboard
🐛 Fix bugs
📚 Write docs

Check out: Contributing Guide

🔗 Links

GitHub: ybentlili/qualityhub
CLI: qualityhub-cli
npm: qualityhub-cli

🎯 Try It Now

# Self-host in 5 minutes
git clone https://github.com/ybentlili/qualityhub.git
cd qualityhub
docker-compose up -d

# Or just the CLI
npm install -g qualityhub-cli
qualityhub parse jest ./coverage

💬 What do you think?

Would you use this? What features would you like to see?

Drop a ⭐ on GitHub if you find this useful!

Built with ❤️ in TypeScript