Бывает на практике, что приходится ревьюить запрос на слияние, и видить подозрительные изменения go.mod и go.sum, возможно меняется только один файл, и возникает закономерный вопрос, а нужны ли эти изменения, или это случайно попало в коммит, быть может коллега забыл добавить другой файл в коммит или запустить go mod tidy после удаления зависимости? А может быть это ты сам в предыдущих коммитах добавил лишние изменения?
В общем возникают вопросы, и чтобы их стало меньше можно автоматизировать проверку актуальности состояния файлов go.mod и go.sum.
На примере Gitlab CI такое задание может выглядеть так:
image: golang:1.21.5
stages:
- check
check-go-dependencies:
stage: check
script:
- go mod tidy
- git diff --exit-code
go mod tidy— это команда которая проверит соответствие исходного кода модуля и файлов go.mod и go.sum.git diff --exit-code— эта команда покажет различия в файлах которые были закоммичены и тем которые получатся после предыдущей команды, выдав не нулевой код выхода если отличия есть.
Это задание простое в реализации, но если оно падает с ошибкой, то не понятно что с этим делать, и хорошо бы добавить полезную информацию для коллег или себя из будущего, о том как эту проблему можно решить. Поэтому внесем некоторые доработки в проверку:
image: golang:1.21.5
stages:
- check
check-go-dependencies:
stage: check
script:
- go mod tidy
- |
git diff --exit-code && exit 0 || true
echo -e "\033[0;31m"
echo '######################################################################'
echo
echo "ERROR: go.mod or go.sum is different from the committed version"
echo "Try using 'go mod tidy' to fix the go.mod and go.sum files"
echo "Also, don't forget to commit and push changes"
echo
echo '######################################################################'
exit 1
В начале всё тот же go mod tidy, а дальше интересней, так-как пайплайн завершается при первой же ошибке сложно разложить проверку на отдельные вызовы команд, по этому за счет синтаксиса - | описываем многострочный скрипт. Далее в случае если git diff ничего не находит то выходим с нулевым кодом, а вот если код выхода не нулевой, то перехватываем и пропускаем его за счет команды true. Далее устанавливаем красный цвет для сообщения, формируем нужное сообщение и выходим с не нулевым кодом чтобы задание завершилось с ошибкой.
В принципе это закрывает основные потребности проверки актуальности go.mod и go.sum, а вывод подробного сообщения об ошибке поможет нам и коллегам узнать о варианте исправления проблемы командой go mod tidy. И в свою очередь должно улучшить пользовательский опыт, и снизить количество вопросов возникающих при падении такой задачи.
P. S. Больше моих статей и оригинал статьи можно найти в моём личном блоге.
P. P. S. Как иллюстрация к статье использовано изображение автора macrovector / Freepik.
