Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Gitlab CI (Continuous Integration) и автотесты

selenium
gitlab
ci
jenkins
webdriver
allure
java
Теги: #<Tag:0x00007fedbfe2d178> #<Tag:0x00007fedbfe2ced0> #<Tag:0x00007fedbfe2cb60> #<Tag:0x00007fedbfe2c8b8> #<Tag:0x00007fedbfe2c520> #<Tag:0x00007fedbfe2c250> #<Tag:0x00007fedbfe97f28>

(Eugene Moskalenko) #1

Всем привет, собираемся переехать с #jenkins на #gitlab CI. Появилась парочка вопросов, может кто работал с этим CI

  1. Хорошее ли это решение для CI?
  2. С какими проблемами придется столкнутся в этой CI в автоматизации? (использую: #maven , #java , #webdriver , #selenide , #allure )
  3. Можно ли прикрутить #allure отчеты на #gitlab? В Google пока не нашел решения. Но думаю, что своими силами что-то должно получиться, без плагинов

Спасибо… Буду рад любой информации, сейчас провожу анализ что к чему… Разработчики сказали, что хотят перейти на это решение по своим каким-то непонятным убеждениям, а мне надо понимать, подойдет ли это решение мне :slight_smile:


(SlavikF) #2

Проблемы, которые я поимел с Gitlab CI:

  • нет возможности задавать параметры для заданий. Всё должно быть прописано в .gitlab-ci.yml. Частично можно решить с помощью Environment, но это не то.
  • нет возможности запустить несколько tasks на одной машине одновременно. Это я про SSH. Там специальный runner для SSH, и пока одна задача не закончится - другая не начнётся с этим runner. В Jenkins можно запускать несколько одновременно. Но есть другие типы runners, может с ними и получится что-то…
  • нет возможности to schedule tasks. Например, чтобы запускались тесты каждую ночь. Можно прописать где-нибудь крон, чтоб он дёргал Gitlab API, но это костыль.

Ничего не знаю про allure…


(Eugene Moskalenko) #3

спасибо, для расписания, думаю напишу крончик, не такой уж и большой минус. А вот Environment - эт конечно проблемка…


(Lev Yarushin) #4

@SlavikF Несколько тасков прекрасно работают через Docker runner (включая SSH)

По поводу allure - в GitLab отчёты можно или забирать из артефактов (благо сейчас наконец-то стало можно это делать при фейле сборки) либо делать как-то так:

tests_1:
  stage: test
  script:
    - set +e
    - [команда запускающая тесты] || EXIT_CODE=$?
    - [команда выгружающая отчёты на ftp]
    - set -e
    - exit ${EXIT_CODE}

(Lev Yarushin) #5

По поводу 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

(Eugene Moskalenko) #6

Спасибо :slight_smile: @LeoRush, а в целом, какое впечатление от GitLab?


(Lev Yarushin) #7

В целом - положительное. GitLab как замена Github вообще супер )
CI там не основное, и ничего в принципе не мешает использовать Jenkins для CI а GitLab для кода.


(Valentin Buryakov) #8

Так сложилось что наш проект был в Gitlab’e и поэтому стали использовать Gitlab CI для запуска unit и ui тестов (protractor). В целом впечатления неплохие, проект активно развивается, каждый месяц новый релиз с крутыми фичами выходит. В последнем релизе вышла интересная штука Review Apps такого вот не встречал пока негде, судя по описанию может здорово помочь тестированию.

  1. Можно создавать свои раннеры и конфигурить их для отедельных джобов, указываешь в джобе tag и он будет использовать только соответсвующий раннер с этим тегом. Также есть возможности указывать для каких веток запускать тесты и тд
  2. Есть свой докер репозиторий, который можно хранить image для своего проекта.
  3. Есть встроенная итеграция со slack и builds email.
  4. Ночной запуск делаем по крон джобу, который триггерит билд и в нем можно указывать свои переменные, по которым смотрим какой тестовый набор запускать.
    Из проблем которые были:
  5. Нет интеграции с тест-репортами, с артифактами всё-таки не очень удобно работать. Пришлось делать свой репортер, когда отсылает письмо с отчетом по свалившимся тестам.
  6. Так и не разобрался можно ли использовать Selenium Grid в таком подходе, когда у нас используется docker executor в котором билдится приложение и запускаются тесты, как туда еще грид вставить, чтобы из него было доступно приложение - непонятно, docker in docker разве что. Параллелим, используя встроенную фичу protractora, которая позволяет сразу в нескольких браузерах запускать тесты.

Спасибо @LeoRush за снипет, как раз искал, что-то подобное для запуска тестов по желанию девелоперов.


(Eugene Moskalenko) #9

спасибо, позновательно, единственное конечно с репортами накладочка получается… :frowning:


(Valentin Buryakov) #10

Возможно в скором будущем что-то придумают для репортинга, по тикетах я видел у них в планах есть такое, хотят полноценную замену дженкису сделать. Мы когда начинали его использовать, так у них и артефактов не было даже ))


(Антон) #11

Здравствуйте, коллеги.
По этой теме какие-то подвижки есть?


(Lev Yarushin) #12

В какую сторону? Новая версия Гитлаба вышла )


(Антон) #13

В сторону удобства параметризации, репортов, грида (паралелизации джобов?)


(Valentin Buryakov) #14

Щас особо не слежу за гитлабом в связи со смненой работы, но вот помню в марте они вот сделали gitlab pages доступными для Community Edtition Gitlab pages, что очень хорошо для тестирования, ведь раньше чтобы посмотреть репорт нужно было скачивать артифакты. Теперь в .yml файле можно определить джобу для pages, в которой можно паблишить наш html-report, что мы получили из тестовой джобы.


(Igor) #15

Помимо GitLab Pages появились возможности:

  • Secret Variables для каждого репозитория;
  • Triggers внутри каждого репозитория.
    Мы активно юзаем variables, это позволяет вызывать общие скрипты в .gitlab-ci.yaml для разных проектов.
    По поводу репортов - их можно отображать в GitLab Pages, но надо как-то привязывать ссылку к билду, у коллег есть идея добавлять ссылку в комментарий.
    По поводу грида, чем не устраивает вариант поднимать грид для каждого билда в виде докер-контейнера? В .gitlab-ci.yaml можно указать в параметре service для stage докер образ и при выполнении стадии контейнер будет развёрнут и сразу в доступен из раннера.

P.S. имхо, если сравнивать с Jenkins, отчёты - единственнное, чего пока не хватает.


(Kirill Remizov) #16

что-то изменилось в плане отчетов? у кого-то получилось интегрировать плотно с allure (просмотр истории тестов, например)?


(Антон) #17

Присоединяюсь к вопросу - очень интересно как получать историю тест ранов и тренды