Comments 4
А ещё можно сделать pre-commit хук, чтобы проблема обнаружилась раньше
Да, такое решение вполне применимо, но не лишено недостатков
pre-commit хук подходит не для всех flow работы с git, и может принести дополнительные неудобства.
Все мы люди и мы банально можем забыть установить pre-commit хук.
Когда мы работаем в команде 1-й и 2-й пункты становятся ещё более актуальными.
A через CI непроверенный код не пройдет, даже если кто-то забыл что-то сделать.
Извиняюсь, непонятно выразился. Да, конечно, pre-commit хук не заменяет проверку CI, а дополняет её, позволяет быстрее обнаружить проблему. Как прогон тестов локально и в CI. А вот когда хук не подходит для flow работы с git, не представляю. Сталкивался с неудобством в Python проекте, когда в существующий проект добавили форматтер, black, в хуки, он форматирует изменённые файлы, а свои изменения отдельно закоммитить сначала - только с --no-verify, потом уже отдельный коммит "Reformat". Но если изначально использовать в проекте, или при добавлении на все файлы прогнать - проблем не должно быть. А конкретно в этом случае, разве может быть нужно только один из изменённых go.mod и go.sum закоммитить?
разве может быть нужно только один из изменённых go.mod и go.sum закоммитить?
Может быть, необходимо внести изменения только в go.mod, например:
обновить версию Go
исправить форматирование секций require
переименовать модуль
добавить toolchain directive
добавить retract directive
добавить Deprecated комментарий
Да, конечно, pre-commit хук не заменяет проверку CI, а дополняет её, позволяет быстрее обнаружить проблему.
Если pre-commit хук использовать только для go mod tidy и не расценивать как замену CI, то это хороший вариант, как по мне.
Если в pre-commit хук добавить все статические проверки, то это становится сильно неудобным, например:
Если нужно сделать быстро прототип и вылить на стенд (не из мастера, а из MR) для интеграции с коллегами, то будет сильно мешать постоянная необходимость использовать -no-verify для создания коммитов.
Если придерживаться чистой истории и в MR ребейзить коммиты, то тоже регулярно нужно будет использовать -no-verify, это банально неудобно.
Это может быть медленно: в зависимости от статических проверок и размера кодовой базы проверки могут занимать десятки секунд или несколько минут. На каждый коммит ждать, например, 30 секунд – это не удобно.
На практике хорошо работают частые коммиты, но они далеко не всегда проходят все проверки (главное, чтобы тесты прошли всё остальное позже), и тут регулярно нужно будет использовать -no-verify – это не удобно
В конечном итоге это может привести к привычке постоянно использовать -no-verify, и вся идея с хуком перестанет работать. Или приведет к отключению pre-commit хука.
В общем, мы работаем с гитом по-разному; исходя из своего опыта, считаю pre-commit хук не удобным. А также считаю, что, если проверки на CI проходят за пару-тройку минут, то вы ничего не потеряете, если забудете какую-то проверку запустить локально.
Проверяем актуальность go.mod и go.sum