11

Git хук для запуска тестов

Есть у меня такой pre-push хук - автоматом прогоняет тесты локально, через maven. Подключается по необходимости через отдельные git конфиги для проектов.

Git хук для запуска тестов IT, Командная оболочка bash, Java, Программирование

Стащил его, судя по всему, отсюда: https://gist.github.com/arnobroekhof/9454645. Потом допиливал немного – чтобы он с многомодульными проектами работал корректно. Может, ещё что-то по мелочи причёсывал.

И он отлично работает (разве что можно через sed попробовать результаты по всем модулям агрегировать).

Но вот проблема – на текущем проекте везде gradle, а под него я что-то не могу найти похожего простого решения

Есть ли оно?

0
DELETED
Автор поста оценил этот комментарий

А не проще на GitHub Actions гонять тесты при слиянии в мастер-ветку?

Ну или там, где ваш гит хостится

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

А как ты сравниваешь вообще локальный прогон до пуша и удалённый после пуша?

>GitHub Actions
>там, где ваш гит хостится
Ну т.е. ты не знаешь, где он хостится и что там доступно. Откуда возникает мысль, что там будет проще гонять?

показать ответы
1
Автор поста оценил этот комментарий

А разве Summary и тд это не JUnit печатает, т.е. не зависит от типа сборочной машины?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Мне казалось, что это какой-нибудь

maven-surefire-plugin делает.
Поискал - ошибаюсь. Похоже, что формат вывода действительно от тестового фреймворка зависит (по умолчанию, по крайней мере).

Т.е. надо этот момент тоже учесть в хуке.

2
Автор поста оценил этот комментарий
Есть, pre-commit хуки отлично работают с градлом.
Вот пример:https://gist.github.com/franklsm1/d15dd2020772fb6ca65a375956...
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Спасибо!

0
DELETED
Автор поста оценил этот комментарий

Maven, gradle... Тьху блин, у вас же java.


Прошу прощения. Никогда рядом даже не проходил, у вас наверняка свои заморочки, нежели у нас, питонистов/перловиков.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

В перле, насколько я помню (а я лет 7 его не трогал) - не было какого-то зоопарка в этом вопросе. Модуль Test, сборка мейкфайлом.

0
DELETED
Автор поста оценил этот комментарий

Очень просто. Локально (перед пушем) я пускаю тесты только той области проекта, которую затрагиваю своим коммитом. Это быстро.


А в раннерах запускаются все тесты после каждого пуша в ветку. Обычно после пуша идет перерыв в виде чая/кофе. По возвращению тесты прогнаны, и если есть красные - разбираемся локально. Но это редкая ситуация.


Затем предфинальные тесты в раннерах после слияния с мастером. И финальная - при деплое на продакт. Есть красные - деплой провален. Всё зеленое - деплой успешен.


Зы: очень сильно подозреваю, что если свой локальный гит - то это gitlab. У него все есть в коробке и для тестов и вообще для полноценного CI/CD.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

>я пускаю тесты только той области проекта, которую затрагиваю своим коммитом
Не уверен, что это так просто сделать через maven. Если есть готовое решение - прошу поделиться.
Gradle, насколько я успел про него прочитать, примерно так и работает из коробки.

Ручной запуск - не интересно, спасибо.


Перед пушем я автоматом пускаю тесты и, в случае проблем, просто сразу вношу правки, причесываю ветку ребейсом, пушу снова. При этом:

- Мне не надо ждать, пока пройдут разные фазы удалённой сборки (тесты там - не первый шаг). Особенно обломно, когда какая-то мелочь уровня опечатки в самом тесте - всё валит.

- Коллегам, подписанным на обновления репо, не придут уведомления об изменениях "запушено/сборка пошла/сборка сдохла на тестах" - пока там не окажется ветка, для которой тесты 99% проходят, т.к. были прогнаны в pre-push фазе.

- Мне не придется задумываться - могу ли я заребейсить ветку и форс пушить её потом, т.к. ветка не выложена удалённо, пока локально не прошли тесты.

Это экономит и моё время, и окружающих.


>У него все есть в коробке и для тестов и вообще для полноценного CI/CD
Если ставить его докером - придется пошаманить немного, чтобы раннеры прикрутить. Т.е. это не будет прямо "из коробки".

Но у меня локально - только голый гит. И в нём из коробки есть хуки.

показать ответы
0
Автор поста оценил этот комментарий

Можно же тупо завязаться на итоговой фразе типа так:

echo "${MVN_RESULT}" | ((tee /dev/fd/5 | grep -A 10 -B 2 "FAILED" > /dev/fd/4) 5>&1 | sed -n -e '/^:test FAILED/,/:test.*$/ p' ) 4>&1


Но это все костыли, нужно за правило взять билдить проект перед пушем с включенными тестами и чекстайлом. Ну про ci/cd с квалити гейтами думаю не нужно говорить, они должны быть и поломаный код не соберется и не раскатится на стенд.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

>билдить проект перед пушем с включенными тестами и чекстайлом
Вот хук пусть этим и занимается, да.

>завязаться на итоговой фразе типа так
Благодарю! Попробую "универсальный" разбор сделать для maven и gradle.

3
Автор поста оценил этот комментарий

Никогда не работал с ними (джаву ковырял лет десять назад), но обычно у всяких систем сборки есть куча опций, флагов, конфигов и всего такого, чтобы настроить форматированный вывод без дополнительного колхоза с башем.


Вот что сходу нагуглилось по "gradle run tests format output":


https://stackoverflow.com/questions/3963708/gradle-how-to-di...

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Гит хук - мой локальный. внести изменения в скрипты гредла - или всё время в stash прятать не забывать, или придётся обосновывать их необходимость.

А вот можно ли такой скрипт заинклюдить как-то только у себя локально из хука, чтобы он прогнался и вывод отформатировал - в эту сторону я не думал. Спасибо за идею.

2
Автор поста оценил этот комментарий

Это же баш скрипт, что если “mvn clean test” заменить на “gradle clean build”?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Это сделать несложно.

Вопрос в парсинге содержимого ${MVN_RESULT} - хочется найти готовое решение для выхлопа gradle.

Просто запустить тесты и упасть с кодом выхода !=0 не особо много смысла для меня.

показать ответы
0
Автор поста оценил этот комментарий

Не проще ли экономить свое время и запускать тесты на CI/билд сервере?

раскрыть ветку (1)
Автор поста оценил этот комментарий

pre-push тесты экономят моё время.