Git ловушка предварительной фиксации для проверки количества изменяемых файлов

Question

В нашем репозитории есть пользовательские проверки состояния, которые запускаются в зависимости от количества файлов, которые мы изменили. Если количество файлов, измененных в одном PR, велико, эти проверки состояния могут привести к снижению зависимости в нисходящем направлении. (есть запросы к сервису, сделанные в этих проверках статуса). Я здесь не для того, чтобы спорить об этих проверках статуса и о том, почему они вообще существуют, в данный момент мы не можем изменить это или масштабировать сервис для обработки такой нагрузки.

Идея скрыть эти большие изменения состоит в том, чтобы добавить хук git для предварительной фиксации, который в основном получает количество файлов, которые отличаются между текущей веткой и кончиком удаленного мастера. Затем мы хотим выдать ошибку, если число этих файлов больше определенного числа.

В основном, я собираюсь сделать это, используя следующие команды в git hook

# Refresh local reference to origin/HEAD
git fetch

# Get the diff between the tip of current branch and the tip of origin/HEAD and count them
git diff --name-only --cached origin/HEAD | wc -l

... 

Кажется, это работает, но у меня есть пара вопросов: 1. Есть ли скрытые ошибки с этим методом? Я хочу убедиться, что покрываю все случаи, когда мы можем предотвратить открытие запроса извлечения с разницей в количестве файлов> X. 2. Безопасно ли вызывать git fetch в git hook? Мне нужен какой-то способ, чтобы гарантировать, что локальная ссылка на источник / HEAD не устарела, иначе ловушка не потерпит неудачу, но запрос на получение все еще может иметь непристойно большую разницу, если локальный мастер устарел.

Answer 1

Да, скрытый момент здесь в том, что этот сервис работает на машинах разработчика, а это означает, что целостность вашей системы CI основана на готовности разработчиков и возможности установить хук pre-commit, а не переопределять его. Как уже упоминалось ранее здесь и в других местах, невозможно полагаться на pre-commit хуки для применения политик, поскольку машинам разработчика не доверяют.

Вам было бы гораздо лучше поместить это в свои скрипты CI и просто потерпеть неудачу рано, если количество изменений велико. Ваша система CI является подходящим местом для принятия политических решений, даже если эти политические решения должны отказаться и не выполнять остальные задания CI. С другой стороны, если ваш Git сервер поддерживает хук pre-receive, вы можете выполнить эту работу там.

Кроме того, подобные хуки pre-commit затрудняют продвинутым пользователям создание серии логических коммитов. или даже создать фиксацию коммитов для сквоша в более старый коммит Как один из таких пользователей, я был бы очень несчастным, если бы мне приходилось ждать выборки каждый раз, когда я хотел добавить некоторые коммиты, и я ожидаю, что ваши пользователи будут удалять ловушку или принудительно использовать --no-verify.

Сказав это, он ничего не сломает для извлечения в хуке pre-commit, хотя вы обнаружите, что это нарушит использование git push --force-with-lease пользователями, а также может привести к путанице в интеграции редактора.