Кратко

  • CODEOWNERS — это конфигурация маршрутизации ответственности по пути и ветке; GitHub может автоматически запрашивать проверку у владельцев, когда нечерновой pull request меняет принадлежащий им код.
  • Результат зависит от файла в базовой ветке, приоритета расположения, последнего совпавшего шаблона, набора изменённых путей и действительных прав владельцев. Файл, видимый сегодня, не удостоверяет вчерашний результат.
  • Надёжная запись проверки должна раздельно хранить применимую конфигурацию, diff, запрос, ответ проверяющего и другие условия слияния. Это редакционный способ сохранить доказательства, а не требование GitHub.

Статическое правило не рассказывает, что произошло

Фраза «владельцы проверили изменение» может звучать законченно, хотя в ней скрыто несколько разных вопросов. Какой была базовая ветка? Какие пути входили в diff? Какой шаблон получил приоритет? Имели ли названные пользователь или команда нужный доступ в тот момент? Был ли запрос отправлен и появился ли ответ на именно этот diff? Была ли вообще проверка владельца обязательной? Отображаемый файл способен дать лишь часть ответа.

GitHub описывает CODEOWNERS как способ определить людей или команды, отвечающие за код репозитория. Когда нечерновой pull request изменяет код с владельцем, GitHub автоматически запрашивает у владельцев проверку. Черновики не получают такого автоматического запроса до перевода в состояние готовности к проверке. Это механизм доставки профессионального внимания, а не свидетельство того, что суждение уже вынесено.

Ветка является частью правила. Каждый файл CODEOWNERS назначает владельцев для одной ветки, а запросы проверки используют его версию в базовой ветке pull request. Если pull request идёт из fork в исходный репозиторий, используется файл базовой ветки исходного репозитория. Поэтому один и тот же патч может получить разных владельцев при направлении в main и в ветку сопровождения. Файл в head-ветке либо версия, которую позднее показывает ветка по умолчанию, не заменяет доказательство действовавшей тогда политики.

Важно и место файла. GitHub ищет .github/, затем корень, затем docs/ и использует первый найденный файл. Файл размером более трёх мегабайт не загружается; сведения о владельцах не показываются, а подходящим владельцам не направляют запрос. Текст политики может существовать в репозитории, но не участвовать в маршрутизации конкретного события.

Последнее совпадение меняет поверхность ответственности

Шаблоны легко принять за накопление правил, но GitHub отдаёт приоритет последнему совпавшему шаблону. Общая строка * может быть вытеснена поздней строкой *.js для изменения JavaScript. Несколько владельцев на одной строке разделяют шаблон; владельцы на разных совпадающих строках не обязательно суммируются — действует последний результат. Если сослаться только на общую строку, не восстановив порядок и пути diff, можно приписать проверку тому, кого система не просила.

Есть и условия действительности. Пути чувствительны к регистру. Строка с неверным синтаксисом пропускается. Несуществующий пользователь или команда без достаточного доступа не назначается владельцем. Это не обвинение конкретного репозитория. Это граница между снимком конфигурации и доказательством события.

GitHub также рекомендует определить владельца для самого файла CODEOWNERS. В этой рекомендации видна задача управления: правило, которое распределяет ответственность, должно иметь наблюдаемый путь собственного изменения. Иначе читатель знает, кто якобы отвечает за код, но не знает, кто мог изменить правило об ответственности.

Запрос, одобрение и слияние — разные записи

GitHub отделяет автоматический запрос проверки от необязательной настройки, требующей одобрения code owner перед слиянием. Второе настраивается отдельно администратором или владельцем репозитория. Если в одном шаблоне несколько владельцев, при включённом требовании может быть достаточно одобрения одного из них. Сам файл не превращает каждое указанное имя в обязательную блокировку слияния.

Кроме того, rulesets и защита веток могут действовать одновременно. Применимые правила агрегируются, а при разных вариантах одного правила используется более строгий. Требование pull request, число одобрений, проверка code owner, status checks, успешное развёртывание, закрытые комментарии, способ слияния и права bypass могут быть отдельными поверхностями контроля. GitHub отмечает, что pull request со всеми необходимыми одобрениями всё ещё может быть заблокирован, если другой открытый pull request с тем же head commit имеет ожидающую или отклонённую проверку.

Одобрение остаётся важным фактом: оно сигнализирует, что изменения выглядят готовыми к слиянию. Однако это состояние проверки заданного diff, а не общий сертификат всех правил и всех последующих действий.

Сохранить подтверждение «конфигурация — проверка»

Для существенного утверждения запись стоит начать с идентификатора pull request, ссылок на базовый и head commit или tree и набора изменённых путей. Затем следует сохранить расположение и идентичность содержимого CODEOWNERS, действовавшего в базовой ветке, выигравший шаблон и разрешённый набор владельцев. После этого фиксируются события: когда был сделан запрос, кто и каким состоянием ответил, какой diff или commit покрывал ответ.

Если утверждение доходит до готовности к слиянию, отдельно нужно назвать применимые rulesets или правила защиты, наблюдаемые состояния их условий и любой документированный bypass. Там, где нет доказательства перехода, повествование должно остановиться. Такая запись не создаёт нового полномочия и не вводит новую процедуру GitHub; она не позволяет выдавать текущую политику за полную историю прошлого события.

Источники

  1. GitHub Docs — About code owners
  2. GitHub Docs — Pull request reviews
  3. GitHub Docs — About rulesets
  4. GitHub Docs — Available rules for rulesets