Path exceptions в GitHub push rules: canary для JAR и крупных файлов без ослабления ruleset. Добавить одно узкое исключение в Allowed exceptions, проверить pattern валидатором GitHub и выполнить два push: разрешённый путь и такой же файл вне исключения. Практический результат — таблица «rule × path pattern × разрешённый fixture × запрещённый fixture…
Исходное состояние без догадок
Наблюдаемый сценарий: Нужно разрешить один известный путь, но глобальное ослабление restrict file path или file size откроет нежелательные изменения во всём репозитории. Сначала зафиксируйте точную дату, версию, область действия и исходное состояние, не меняя несколько параметров одновременно. Рабочая последовательность: Добавить одно узкое исключение в Allowed exceptions, проверить pattern валидатором GitHub и выполнить два push: разрешённый путь и такой же файл вне исключения. Официальное изменение формулируется уже: 25 августа 2026 года GitHub добавил public preview path exceptions для push rules Restrict file paths и Restrict file size с проверкой patterns при сохранении ruleset. Оно подтверждает наличие новой возможности или исправления, но не доказывает, что именно оно вызвало любой похожий симптом. Поэтому запись до теста должна содержать только обезличенные признаки: роль, тип объекта, видимый статус и время. Имена людей, приватные URL, токены, содержимое рабочих файлов и полные логи в публичную заметку не переносятся.
Два уровня доказательств
Первичный источник сообщает: 25 августа 2026 года GitHub добавил public preview path exceptions для push rules Restrict file paths и Restrict file size с проверкой patterns при сохранении ruleset. Второй официальный материал задаёт рабочую границу: Документация описывает push rules, pattern syntax и области применения; она служит контрактом для контрольных fixtures. Эти два уровня нельзя смешивать: changelog подтверждает дату и новое поведение, а документация объясняет штатную модель и доступные действия. Для этого intent полезен артефакт: таблица «rule × path pattern × разрешённый fixture × запрещённый fixture × результат push × rollback commit». Он не объявляет популярность проблемы и не превращает единичное наблюдение в универсальную причину. Если интерфейс, edition или permissions отличаются от источника, отметьте это как отдельную неизвестную ветку. Сниппет поиска и обсуждение сообщества остаются лидом; вывод принимается только после совпадения прямой страницы, версии и контрольного результата.
Безопасный canary
Обратимый тест: В тестовой ветке использовать два безвредных файла одинакового типа или размера, расположенные внутри и снаружи pattern; после проверки удалить исключение и повторить запрет. До шага сохраните исходное значение и способ возврата. Меняйте ровно одно условие, после чего повторяйте тот же вход, объект и критерий успеха. Результат заносите в таблица «rule × path pattern × разрешённый fixture × запрещённый fixture × результат push × rollback commit». Положительный исход означает лишь связь с изменённым условием в этом окружении; отрицательный исход исключает только проверенную ветку. Повтор на другом аккаунте, репозитории, профиле или документе допустим лишь с тестовыми данными и тем же build. Не подменяйте воспроизводимость серией случайных очисток, переустановок или массовых переключений.
Чтение before/after
Читайте результат по границам. Если контрольное действие выполняется и исходный симптом исчезает только после ожидаемой штатной настройки, сохраните точную пару before/after и проверьте возврат. Если симптом остаётся, вернитесь к исходному состоянию и переходите к соседней ветке из формулировки: Добавить одно узкое исключение в Allowed exceptions, проверить pattern валидатором GitHub и выполнить два push: разрешённый путь и такой же файл вне исключения. Если поведение различается между уровнями организации, профилями или типами объектов, сначала вычислите effective setting и права текущего пользователя. Если различается только визуальный вход, проверьте, не сохранилась ли сама функция по другому маршруту. Ни дата релиза, ни совпадение названия не доказывают регрессию. Доказательством служит повторяемая матрица с одной переменной и официальной границей поведения.
Минимальная эскалация
Стоп-линия: Не использовать широкие glob, не исключать каталоги секретов или сборочных артефактов целиком и не переносить preview-настройку на все repositories без canary. Если нужна эскалация, подготовьте минимальный пакет: точный build, UTC-время, тип аккаунта или профиля, обезличенный идентификатор объекта, ожидаемый и фактический результат, один контрольный шаг и итог возврата. Скриншот обрежьте до нужной области; удалите имена, email, внутренние пути, суммы, токены, адреса и содержимое документов. Не прикладывайте полный HAR, database, профиль браузера или конфигурацию организации без отдельного защищённого канала. Практический итог статьи — таблица «rule × path pattern × разрешённый fixture × запрещённый fixture × результат push × rollback commit». Он позволяет поддержке воспроизвести конкретную границу и не требует опасных или необратимых действий.
Материал подготовлен редакцией VOne с помощью ИИ; все технические утверждения постатейно сверены с указанными официальными источниками 28 августа 2026 года.
Источники и проверка
- Официальный changelog или release notes проверено 2026-08-28
- GitHub Docs — Available rules for rulesets проверено 2026-08-28
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.