Rosentic

Что такое Rosentic?

Rosentic — это детерминированная проверка CI, которая сканирует pull request (PR) по активным веткам, чтобы находить конфликты совместимости перед merge. Она фокусируется на случаях, нарушающих поведение между ветками, включая schema drift, API breaks и несоответствия подписей.

Рабочий процесс построен на автоматизированной верификации: для события PR Rosentic запускается в вашем CI, выдаёт разбор breaking changes и сообщает конкретные места (пути к файлам и номера строк), связанные с обнаруженными конфликтами.

Ключевые возможности

• Сканирует PR по всем активным веткам перед merge, чтобы ловить несовместимости между ветками, а не только проблемы в diff самого PR.
• Детерминированное выполнение для консистентных результатов в разных запусках CI.
• Запускается в вашем CI/runner («code never leaves your runner»), сохраняя анализ в существующей среде сборки.
• Поддержка 12 языков в соответствии с заявленным охватом сканирования.
• Предоставляет разбор на уровне строк (пути к файлам и номера строк) для конфликтов, чтобы команды могли исправить точные места вызовов и интерфейсы.
• Использует regression fixtures для защиты изменений в базовом движке.

Как использовать Rosentic

1. Добавьте workflow GitHub Actions от Rosentic в репозиторий (на сайте есть пример .github/workflows/rosentic.yml).
2. Настройте workflow на запуск по событиям pull_request, нацеленным на ветки (в примере branches: [main]).
3. Убедитесь, что workflow checkout репозитория использует fetch-depth: 0 (как в примере), чтобы Rosentic мог проверить нужное для сравнения веток.
4. Workflow запускает Rosentic/rosentic-action@v1. После завершения задания просмотрите отчёт Rosentic о «Breaking» конфликтах и местах на уровне строк в выводе.

Для запуска в агент-based workflow сайт также рекомендует установить Rosentic в репозиторий, а затем указать агенту следовать этой инструкции.

Сценарии использования

• Предотвращение сбоев во время выполнения или интеграции перед merge: PR меняет сигнатуру функции (например, добавляет обязательные аргументы), и Rosentic находит оставшиеся вызовы на других ветках, использующие старую сигнатуру.
• Обнаружение schema drift между ветками: Когда обновления кода затрагивают определения схем (например, меняется resolver или форма контракта), Rosentic сообщает о «Schema drift» и указывает на затронутые файлы/строки.
• Ловля изменений типов возврата API или контрактов: Если тип возврата функции меняется (например, с Promise<void> на другую форму Promise<Result>), Rosentic перечисляет вызовы, которые могут не обработать новую структуру результата.
• Защита от несовпадающих интерфейсов между backend и frontend: Когда PR обновляет общие интерфейсы, Rosentic отмечает конфликты типа «signature mismatch», где места вызовов в других ветках не совпадают.
• Стандартизация проверок совместимости для нескольких веток агентов: Если команда использует несколько веток и автоматизированных workflow, Rosentic проверяет совместимость между ветками, снижая вероятность конфликтов с параллельной разработкой.

FAQ

Требует ли Rosentic API-ключ или регистрацию?
На сайте указано: «No signup» и «No API key».

Где запускается Rosentic?
Сайт указывает, что он работает в вашем CI/runner, и код «never [leaves] your runner».

Когда Rosentic проверяет конфликты?
Пример workflow запускается по событиям pull_request (с branches: [main] в примере), и Rosentic проверяет PR по активным веткам перед merge.

Какие конфликты сообщает Rosentic?
Примеры на странице упоминают категории вроде schema drift, API break и signature mismatch с разбором конкретных breaking changes и затронутых мест.

Какую информацию возвращает Rosentic?
Сайт указывает, что результаты включают пути к файлам и номера строк, полный разбор и счётчики найденных конфликтов в PR.

Альтернативы

• Автоматизированные тестовые наборы в CI: Вместо проактивного сравнения PR с другими ветками unit/integration-тесты проверяют поведение во время выполнения. Это отличается тем, что тесты верифицируют конкретные сценарии, а не перечисляют конфликты интерфейсов между ветками.
• Статическая проверка типов и линтинг (специфично для языка): Проверщики типов и линтеры могут ловить несоответствия подписей и типов в пределах того, что анализирует компилятор, но могут не выявлять проблемы совместимости, возникающие из изменений относительно других активных веток.
• Обычное обнаружение конфликтов слияния на базе Git: Git может выявлять текстовые конфликты при слиянии, но не проверяет семантическую совместимость, такую как schema drift или несоответствия контрактов API между ветками.
• Инструменты анализа влияния изменений для CI: Инструменты категории анализа зависимостей/влияния фокусируются на том, как изменения влияют на downstream-потребителей; по сравнению с Rosentic они могут больше полагаться на графы зависимостей или покрытие, а не на явную верификацию между ветками.