Можно ли прикрутить #allure отчеты на #gitlab? В Google пока не нашел решения. Но думаю, что своими силами что-то должно получиться, без плагинов
Спасибо… Буду рад любой информации, сейчас провожу анализ что к чему… Разработчики сказали, что хотят перейти на это решение по своим каким-то непонятным убеждениям, а мне надо понимать, подойдет ли это решение мне
нет возможности задавать параметры для заданий. Всё должно быть прописано в .gitlab-ci.yml. Частично можно решить с помощью Environment, но это не то.
нет возможности запустить несколько tasks на одной машине одновременно. Это я про SSH. Там специальный runner для SSH, и пока одна задача не закончится - другая не начнётся с этим runner. В Jenkins можно запускать несколько одновременно. Но есть другие типы runners, может с ними и получится что-то…
нет возможности to schedule tasks. Например, чтобы запускались тесты каждую ночь. Можно прописать где-нибудь крон, чтоб он дёргал Gitlab API, но это костыль.
@SlavikF Несколько тасков прекрасно работают через Docker runner (включая SSH)
По поводу allure - в GitLab отчёты можно или забирать из артефактов (благо сейчас наконец-то стало можно это делать при фейле сборки) либо делать как-то так:
tests_1:
stage: test
script:
- set +e
- [команда запускающая тесты] || EXIT_CODE=$?
- [команда выгружающая отчёты на ftp]
- set -e
- exit ${EXIT_CODE}
По поводу Environment - я решал это через commit message.
В GitLab, при наличии в нем [ci skip] CI после коммита не срабатывает.
На основе этого сделал возможность разработчикам запускать различные варианты тестов.
Возможно кому-то пригодится
Для этого в
before_script:
- if [[ ${COMMIT_MESSAGE} == *\[ci\ test\]* ]]; then export CI_TEST="1"; fi
А в
tests:
stage: test
script:
- if [ -z "$CI_TEST" ]; then exit 0; fi
В целом - положительное. GitLab как замена Github вообще супер )
CI там не основное, и ничего в принципе не мешает использовать Jenkins для CI а GitLab для кода.
Так сложилось что наш проект был в Gitlab’e и поэтому стали использовать Gitlab CI для запуска unit и ui тестов (protractor). В целом впечатления неплохие, проект активно развивается, каждый месяц новый релиз с крутыми фичами выходит. В последнем релизе вышла интересная штука Review Apps такого вот не встречал пока негде, судя по описанию может здорово помочь тестированию.
Можно создавать свои раннеры и конфигурить их для отедельных джобов, указываешь в джобе tag и он будет использовать только соответсвующий раннер с этим тегом. Также есть возможности указывать для каких веток запускать тесты и тд
Есть свой докер репозиторий, который можно хранить image для своего проекта.
Есть встроенная итеграция со slack и builds email.
Ночной запуск делаем по крон джобу, который триггерит билд и в нем можно указывать свои переменные, по которым смотрим какой тестовый набор запускать.
Из проблем которые были:
Нет интеграции с тест-репортами, с артифактами всё-таки не очень удобно работать. Пришлось делать свой репортер, когда отсылает письмо с отчетом по свалившимся тестам.
Так и не разобрался можно ли использовать Selenium Grid в таком подходе, когда у нас используется docker executor в котором билдится приложение и запускаются тесты, как туда еще грид вставить, чтобы из него было доступно приложение - непонятно, docker in docker разве что. Параллелим, используя встроенную фичу protractora, которая позволяет сразу в нескольких браузерах запускать тесты.
Спасибо @LeoRush за снипет, как раз искал, что-то подобное для запуска тестов по желанию девелоперов.
Возможно в скором будущем что-то придумают для репортинга, по тикетах я видел у них в планах есть такое, хотят полноценную замену дженкису сделать. Мы когда начинали его использовать, так у них и артефактов не было даже ))
Щас особо не слежу за гитлабом в связи со смненой работы, но вот помню в марте они вот сделали gitlab pages доступными для Community Edtition Gitlab pages, что очень хорошо для тестирования, ведь раньше чтобы посмотреть репорт нужно было скачивать артифакты. Теперь в .yml файле можно определить джобу для pages, в которой можно паблишить наш html-report, что мы получили из тестовой джобы.
Triggers внутри каждого репозитория.
Мы активно юзаем variables, это позволяет вызывать общие скрипты в .gitlab-ci.yaml для разных проектов.
По поводу репортов - их можно отображать в GitLab Pages, но надо как-то привязывать ссылку к билду, у коллег есть идея добавлять ссылку в комментарий.
По поводу грида, чем не устраивает вариант поднимать грид для каждого билда в виде докер-контейнера? В .gitlab-ci.yaml можно указать в параметре service для stage докер образ и при выполнении стадии контейнер будет развёрнут и сразу в доступен из раннера.
P.S. имхо, если сравнивать с Jenkins, отчёты - единственнное, чего пока не хватает.
для своего проекта я написал скрипт, который перекладывает историю тестов из репорта в резалтс и генерит новый отчет с историей и трендами.
Получившийся новый репорт публикуем на стенде с помощью IIS
testomat.io управление авто тестами
