разве может быть нужно только один из изменённых 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 проходят за пару-тройку минут, то вы ничего не потеряете, если забудете какую-то проверку запустить локально.
приходится настраивать доп. окружение (docker, env и т.д.) для запуска тестов;
Да, в начале внедрения нужно подготовить docker-compose.yml, Makefile и пакет вида testingpg, но потом вся настройка заключается только в установке docker и docker-compose, а дальше можно просто запускать тесты.
Перед первым запуском поднимаем окружение:
make test-env-up
Далее спокойно запускаем тесты через IDE или следующие команды:
Может быть, необходимо внести изменения только в go.mod, например:
обновить версию Go
исправить форматирование секций require
переименовать модуль
добавить toolchain directive
добавить retract directive
добавить Deprecated комментарий
Если pre-commit хук использовать только для go mod tidy и не расценивать как замену CI, то это хороший вариант, как по мне.
Если в pre-commit хук добавить все статические проверки, то это становится сильно неудобным, например:
Если нужно сделать быстро прототип и вылить на стенд (не из мастера, а из MR) для интеграции с коллегами, то будет сильно мешать постоянная необходимость использовать -no-verify для создания коммитов.
Если придерживаться чистой истории и в MR ребейзить коммиты, то тоже регулярно нужно будет использовать -no-verify, это банально неудобно.
Это может быть медленно: в зависимости от статических проверок и размера кодовой базы проверки могут занимать десятки секунд или несколько минут. На каждый коммит ждать, например, 30 секунд – это не удобно.
На практике хорошо работают частые коммиты, но они далеко не всегда проходят все проверки (главное, чтобы тесты прошли всё остальное позже), и тут регулярно нужно будет использовать -no-verify – это не удобно
В конечном итоге это может привести к привычке постоянно использовать -no-verify, и вся идея с хуком перестанет работать. Или приведет к отключению pre-commit хука.
В общем, мы работаем с гитом по-разному; исходя из своего опыта, считаю pre-commit хук не удобным. А также считаю, что, если проверки на CI проходят за пару-тройку минут, то вы ничего не потеряете, если забудете какую-то проверку запустить локально.
Да, такое решение вполне применимо, но не лишено недостатков
pre-commit хук подходит не для всех flow работы с git, и может принести дополнительные неудобства.
Все мы люди и мы банально можем забыть установить pre-commit хук.
Когда мы работаем в команде 1-й и 2-й пункты становятся ещё более актуальными.
A через CI непроверенный код не пройдет, даже если кто-то забыл что-то сделать.
Да, в начале внедрения нужно подготовить docker-compose.yml, Makefile и пакет вида testingpg, но потом вся настройка заключается только в установке docker и docker-compose, а дальше можно просто запускать тесты.
Перед первым запуском поднимаем окружение:
Далее спокойно запускаем тесты через IDE или следующие команды:
Без дополнительной настройки env и так далее.
Не совсем понятно какой сервер, и почему это для нас проблема. В предлагаемом подходе используется СУБД на машине разработчика.