GitHub опубликовал простые правила, которые обеспечат защиту веток и согласованность кода в общедоступных репозиториях. Они позволят защитить несколько шаблонов веток, используя один набор правил, пропускать проверки состояния без дополнительных разрешений, а администраторам — обходить запросы на вытягивание, по-прежнему требуя выполнения важных проверок CodeQL.
Правила доступны на обзорной странице, в Git и GitHub CLI.
В Twilio также включили эти правила, сохранив автономию инженерных команд.
Клиенты GitHub Enterprise Cloud также могут применять их для всех или части своих репозиториев в организации. Изначально правила можно опробовать в режиме оценки. Аналитика позволит отследить, что произойдёт при отклонении устаревших обзоров или включении истории линейного слияния.
Правила обеспечат согласованность с помощью новых правил метаданных. Именами веток, сообщениями о фиксации и адресами электронной почты контрибьюторов можно управлять для обеспечения соблюдения организационных стандартов.
Правила репозитория помогут сохранить качество кода, предотвратить ошибки и улучшить совместную работу. Но для начала нужно чётко сформулировать цели репозитория и ограничить количество правил, отмечают в GitHub.
Рабочий репозиторий должен включать несколько хорошо известных веток, которые будут требовать рецензируемых запросов на вытягивание, использовать CI/CD для запуска модульных тестов и контроля выпусков, а также поддерживать определённые пространства имен тематических веток с минимальными ограничениями. Всё это можно реализовать с помощью REST API.POST /repos/{owner}/{repo}/rulesets { "name": "team rules-ex-1", "target": "branch", "enforcement": "active", "conditions": { "ref_name": { "include": [ "~DEFAULT_BRANCH", "refs/heads/feature-*" ], "exclude": [ "refs/heads/dev-*" ] } }, "rules": [ { "type": "pull_request", "parameters": { "require_code_owner_review": false, "require_last_push_approval": true, "dismiss_stale_reviews_on_push": false, "required_approving_review_count": 2, "required_review_thread_resolution": false } }, { "type": "required_status_checks", "parameters": { "required_status_checks": [ { "context": {status check context name}", "integration_id":{integration ID that this status check must originate from.} } ], "strict_required_status_checks_policy": false } }, { "type": "deletion" }, { "type": "non_fast_forward" } ] }
Использование набора правил в режиме оценки позволяет моделировать потенциальные сценарии, требующие исключений.POST /orgs/{org}/rulesets { "name": " + ", "target": "branch", "source_type": "Organization", "enforcement": "active", "bypass_actors": [ { "actor_id": 1, "actor_type": "OrganizationAdmin", "bypass_mode": "pull_request" } ], "conditions": { "repository_name": { "exclude": [], "include": [ "~ALL" ] }, "ref_name": { "exclude": [], "include": [ "~DEFAULT_BRANCH" ] } }, "rules": [ { "type": "deletion" }, { "type": "non_fast_forward" }, { "type": "pull_request", "parameters": { "require_code_owner_review": false, "require_last_push_approval": false, "dismiss_stale_reviews_on_push": false, "required_approving_review_count": 2, "required_review_thread_resolution": false } } ] }
Правила репозитория поддерживают многоуровневость. Можно написать пару наборов правил, один со списком обхода, а другой — с пустым списком обхода. В этом случае бот может пропускать проверки статуса, но не может удалять ветки или выполнять принудительную отправку.
В апреле GitHub запустил функцию правил в режиме бета-тестирования. Просматривать список правил может любой пользователь с правами на чтение, а менять — только редакторы и владелец.
Источник новости: habr.com
