GitHub Code Quality: code coverage прямо в pull request

Зачіпка

Coverage корисний тільки тоді, коли reviewer бачить його в момент рішення. Якщо відсоток покриття лежить в окремому сервісі, окремій вкладці або десь у CI artifact, його легко проігнорувати.

26 травня 2026 GitHub додав code coverage прямо в pull requests у public preview для GitHub Code Quality. Ідея проста: тестовий job генерує Cobertura XML, GitHub Actions завантажує його через actions/upload-code-coverage@v1, а в PR з’являється summary від github-code-quality[bot].

Проблема / контекст

Багато команд уже запускають тести в CI, але reviewer все одно не бачить нормального coverage signal у тому місці, де вирішує: merge чи ще ні. У кращому випадку є зелена галочка test job. У гіршому — треба відкривати Codecov, Coveralls, HTML report або артефакт build-а.

Зелена галочка не відповідає на просте питання: чи тестували зміни, які зараз додаються? PR може пройти всі тести й водночас принести новий код без жодного покриття. Саме тут coverage summary у PR корисний: він не замінює review, але додає reviewer-у ще один видимий сигнал.

GitHub не робить це магічно. Потрібні три речі:

• увімкнений GitHub Code Quality для репозиторію;
• coverage report у форматі Cobertura XML;
• workflow з правом code-quality: write, який завантажує report у GitHub.

Чому це важливо

Coverage у PR зменшує перемикання контексту. Reviewer уже дивиться diff, коментарі, checks і статуси. Якщо там же видно aggregate coverage і per-file breakdown, команда швидше помічає очевидну проблему: новий файл додали, логіку змінили, а тестів немає.

Це особливо корисно для команд, які вже живуть у GitHub Team або Enterprise Cloud і не хочуть підтримувати окремий coverage-сервіс тільки заради базового reviewer signal. Під час public preview GitHub Code Quality не білиться окремо, хоча workflow все одно витрачає GitHub Actions minutes.

Але не треба перебільшувати. Це не чарівна заміна всіх quality platform. Якщо вам потрібна глибока історія coverage, складні правила по командах, multi-repo аналітика або кастомні quality gates, окремий інструмент може лишатися потрібним. GitHub coverage у PR — це насамперед нативний сигнал для щоденного review.

Як це зробити

1. Перевірте доступність

Спочатку перевірте план і права. GitHub описує Code Quality для GitHub Team і GitHub Enterprise Cloud. Увімкнути його можуть repository owners, organization owners або користувачі з admin role.

Якщо repo на GitHub Enterprise Server або у плані без Code Quality, не починайте з YAML. Спочатку з’ясуйте availability, інакше отримаєте красивий workflow, який нікуди не зможе завантажити дані.

2. Згенеруйте Cobertura XML

GitHub приймає coverage report у форматі Cobertura XML. Мова не принципова: важливо, щоб ваш test framework міг створити або сконвертувати такий файл.

Приклади:

# Python
pytest --cov=. --cov-report=xml

# JavaScript / TypeScript з nyc
nyc report --reporter=cobertura

# Go через coverprofile і конвертер
go test -coverprofile=cover.out ./...
gocover-cobertura < cover.out > coverage.xml

Не починайте з upload action. Спочатку локально або в CI переконайтесь, що файл справді існує, має очікуваний шлях і відповідає саме тому коду, який тестувався.

3. Додайте upload step

Мінімальний GitHub Actions pattern такий:

name: Code Coverage

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read
  code-quality: write

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}

      - name: Install dependencies
        run: npm ci

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

      - name: Upload coverage report
        if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository
        uses: actions/upload-code-coverage@v1
        with:
          report: coverage/cobertura-coverage.xml
          language: JavaScript
          label: code-coverage/unit

Дві деталі тут не декоративні.

Перша: workflow має запускатися і на push до default branch, і на pull_request. GitHub порівнює PR branch із default branch, тому потрібен baseline.

Друга: code-quality: write — це окремий fine-grained permission для upload coverage. Не давайте workflow ширші права тільки тому, що так швидше.

4. Обережно з forked PR

У прикладі upload step має if, який пропускає завантаження для pull requests з forked repository. Це потрібно, бо чужий fork не має отримувати такий самий trust level, як branch у вашому repo.

Тести для forked PR можуть запускатися, але upload coverage у GitHub Code Quality краще робити тільки там, де ви контролюєте джерело workflow і permissions.

5. Перевірте перший PR

Після merge workflow на default branch відкрийте тестовий PR. Коли CI завершиться, шукайте коментар від github-code-quality[bot]. Він має показати aggregate coverage для PR branch порівняно з default branch і per-file breakdown.

Якщо коментаря немає, перевірте по черзі:

• Code Quality справді enabled;
• Cobertura XML створюється;
• шлях у report: правильний;
• workflow має code-quality: write;
• push baseline на default branch уже пройшов;
• PR не з fork, для якого upload навмисно пропущений.

Антипатерни

Не робіть coverage gate занадто рано. Спочатку кілька PR подивіться на реальні numbers і noise. Якщо одразу поставити жорсткий threshold, команда може почати гратися з метрикою замість покращення тестів.

Не плутайте coverage з якістю тестів. Високий відсоток не означає, що перевірені всі важливі сценарії. Він означає тільки, що код виконувався під час тестів.

Не тримайте два coverage upload-и без потреби. Якщо GitHub coverage замінює сторонній базовий upload, приберіть дубль, щоб reviewer не отримував два суперечливі коментарі.

Висновок

GitHub Code Quality coverage у PR — хороший маленький rollout для команд, які вже тестують код у GitHub Actions. Найкращий перший крок: один репозиторій, один test job, Cobertura XML, actions/upload-code-coverage@v1, code-quality: write і тестовий PR.

Якщо після цього reviewer-и справді почали дивитись на coverage поруч із diff, фіча виконала свою роботу. Якщо ні — не додавайте ще один gate заради gate-а, а спочатку розберіться, який signal команді реально допомагає merge-ити спокійніше.