Coroid завершает работу, создавая собственную ветку pull request на основе вашей базовой ветки. Он никогда не выполняет слияние самостоятельно. Решение о слиянии всегда принимает человек — либо в вашем провайдере, либо через Утвердить и слить в Coroid. См. Слияние.
Что входит в состав изменений
- изменения кода
- тесты, написанные или обновленные вместе с ними
- результат выполнения вашего существующего набора тестов
- итог проверки любых правил качества, настроенных в вашей организации
- проверка различий с найденными ошибками, которые уже исправлены или указаны в отчете
Суть не в замене вашей проверки. Просто ваша проверка не должна быть первой.
main- Изменения в коде4 файла
- Написанные или обновлённые тесты2 файла
- Ваш существующий набор тестовУспешно пройдено
- Правила проверки качества1 рекомендация по улучшению
- Успешное прохождение ревью2 исправления, 1 пункт в списке
На что именно обратить внимание
Технические аспекты уже проверены. Сосредоточьтесь на том, что может оценить только вы:
- Решает ли это нужную проблему? Сопоставьте результат с критериями приемки из спецификации, а не со своими воспоминаниями о запросе.
- Соответствует ли это структуре кода? Соблюдение стандартов, именование, структура абстракций. Coroid анализирует ваш код, чтобы определить эти параметры, и в большинстве случаев делает это верно — но не всегда.
- Какие элементы затронуты неожиданно? Посмотрите на список файлов перед просмотром различий.
- Являются ли новые тесты полезными? Тест, который проходит, но ничего не проверяет, хуже, чем его отсутствие.
Отправка работы на доработку
У вас есть три варианта, от наименее затратных к более сложным:
- Оставить комментарий и запросить доработку — задача возвращается агенту-разработчику с вашими замечаниями, при этом контекст сохраняется. Лучший вариант для случаев «всё верно, но неполно».
- Отклонить план и запустить заново — когда подход ошибочен, а не реализация.
- Отменить задачу — когда работа вообще не нужна. Отмена останавливает выполнение и освобождает слот агента.
Будьте конкретны в комментариях к доработкам так же, как вы бы общались с коллегой. «Здесь не обрабатывается пустой случай в parseRange«Производит исправление; «требует доработки» приводит к
ошибочному предположению.
Слияние
Coroid никогда не выполняет слияние самостоятельно. Нет настройки, которая заставляла бы его сливаться после завершения задачи. Слияние происходит двумя способами, и в каждом случае решение о слиянии принимает человек.
Это касается работы, начатой под директивой также. Coroid записывает свое предполагаемое решение по каждому слиянию для оценки собственной точности, но никогда не действует на основе этих записей. См. Что решает Coroid, и что остается за вами.
В GitHub или GitLab
Слейте pull request в вашем провайдере, используя стандартные правила защиты веток, обязательные проверки и требования к утверждению. pull request — это обычная ветка — так и задумано — поэтому она проходит через те же процессы ревью и CI, которым вы уже доверяете.
Из Coroid с кнопкой «Approve & merge»
На экранах ревью в Coroid есть Approve & merge кнопка. Она просит вас подтвердить действие, после чего Coroid сливает pull request за вас через GitHub или GitLab, используя соединение с репозиторием проекта. Это то же самое слияние, что и при нажатии кнопки слияния в вашем провайдере, поэтому применяются правила защиты веток, обязательные проверки и требования к утверждению. Если они блокируют слияние, Coroid отображает причину от провайдера, и ничего не сливается.
То, что происходит перед слиянием, зависит от того, что вы утверждаете:
- Задача. Для задачи сначала нужен pull request. Если его еще нет, на экране ревью будет предложено Создать PR перед Approve & merge. Когда вы утверждаете задачу, Coroid отправляет ветку задачи, чтобы pull request получил последние проверенные коммиты, а затем сливает pull request. Для утверждения задачи требуется права записи в проект.
- План. Задачи, входящие в план, нельзя сливать по отдельности. Слияние единого pull request плана происходит после утверждения на этапе продвижения. Сначала Coroid проверяет, не изменилась ли базовая ветка с момента начала плана (см. Когда меняется базовая ветка), проходят обязательные проверки качества, в pull request нет конфликтов слияния, и ни одно ограничение этапа не блокирует процесс. После этого pull request сливается. Для утверждения плана требуются права записи в проект.
- Принудительное слияние. На этапе продвижения плана также доступно Принудительное слияние. Оно обходит проверки базовой ветки, конфликтов слияния и ограничений этапов в Coroid, но не обходится обязательные проверки качества или правила вашего провайдера. Для этого требуется письменное обоснование, которое сохраняется вместе с данными о продвижении, а также права администратора проекта.
Это Чат-ассистент и Клиенты MCP также могут утверждать или принудительно объединять pull request. Они действуют от вашего имени, поэтому к ним применяются те же проверки и права доступа к проекту. Чат-ассистент всегда сначала запрашивает у вас подтверждение. Принудительное объединение от клиента MCP всегда ожидает в Согласования для человека. То, будет ли утверждение от клиента MCP там ожидать, зависит от ваших политик автоматизации. Ни один из них не может объединить одну задачу.
Подготовьте то, что будет выпущено
После объединения откройте вкладку вашего проекта Релизы и выберите Новый релиз. Выберите коммит объединения, который нужно выпустить; Coroid покажет список содержащихся в нем запросов на объединение. На странице релиза каждая среда пройдет через четыре этапа: проверка, утверждение, развертывание и проверка состояния. Развертывание по-прежнему осуществляется вашим репозиторием и CI/CD. Coroid помечает релиз как развернутый только после подтверждения конвейером или когда Владелец или Администратор зафиксируют подтвержденное внешнее развертывание.
Далее
Релизы — подготовьте коммит объединения и проследите за его прохождением через каждую среду. Что делать дальше перечисляет другие рабочие процессы.