Тесты на pytest с генерацией отчетов в allure с использованием docker и gitlab pages и частично selenium / хабр

Определение образа сборки Docker

Чтобы увидеть, как приложение Node.js выполняется в зависимости от фиксаций GitHub, мы создадим образ Docker для выполнения приложения. Образ строится на основе файла Dockerfile, определяющего конфигурацию контейнера, в котором выполняется приложение.

Измените путь SSH-подключения к виртуальной машине, задав каталог рабочей области Jenkins, имя которого соответствует заданию, созданному на предыдущем шаге. В текущем примере это будет HelloWorld.

Создайте файл в этом каталоге рабочей области с и вставьте следующее содержимое. Убедитесь, что весь файл Dockerfile скопирован правильно, особенно первая строка:

Этот файл Dockerfile использует базовый образ Node.js с помощью Alpine Linux, предоставляет порт 1337, по которому выполняется приложение Hello World, а затем копирует файлы приложения и инициализирует его.

Подготовление к запуску #maven

Мавен делает сборки проектов. Делается это через командную строку. Чтобы мавен знал что и как собрать, а так же что туда добавить (например зависимости — dependencies) мы все это описываем в файле pom.xml который лежит в корне проекта.

Для облегчения процесса сборки и создания файла для эклипса был создан плагин m2eclipse. Установить m2eclipse можно прямо с эклипса в окне Install New Software (Help).

Будем работать через этот плагин, он фактически является графическим интерпретатором кода который заносится в pom.xml.

Итак, установили m2e плагин, теперь делаем из проекта — мавен проект — правой кнопкой на проект Configure — Convert to #maven project.

Заполняем форму и получаем pom.xml файл в корне папки проекта.

Dependency

Так как в нашем проекте есть как минимум две зависимости (dependency) это и необходимо их внести в пом файл.
Для этого заходим в него (двойной клик) и выбираем вкладку
и там начинаем вводить в третей строчке для поиска — “testng”, находим нужный нам () и добавляем. Так же находим и селениум написав “selenium java” и выбрали последний билд.

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

Обновляем пом файл чтобы оно видело testng.xml который покажет какие методы запускать.

вставить нужно такой код:

Готовый pom.xml файл

Итак у нас есть готовый пом файл, проверим на всякий случай его исходник чтобы быть увереными что все в нем есть:

нам для запуска необходимо иметь минимум два плагина maven-compiler-plugin и maven-surefire-plugin (в тегах которого мы прописали наш testng.xml), а так же для нашего проекта подключенные две зависимости тестэнджи и селениум, +.

Получился такой код pom.xml:

First step, running up the services

Since one of the goals is to obtain the report of our project, we should be able to access sonarqube from the jenkins service. is a best choice to run services working together. We configure our application services in a yaml file as below.

version: '3.2'
services:
  sonarqube:
    build:
      context: sonarqube/
    ports:
      - 9000:9000
      - 9092:9092
    container_name: sonarqube
  jenkins:
    build:
      context: jenkins/
    privileged: true
    user: root
    ports:
      - 8080:8080
      - 50000:50000
    container_name: jenkins
    volumes:
      - /tmp/jenkins:/var/jenkins_home #Remember that, the tmp directory is designed to be wiped on system reboot.
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - sonarqube

Paths of docker files of the containers are specified at context attribute in the docker-compose file. Content of these files as follows.

If we run the following command in the same directory as the file, the Sonarqube and Jenkins containers will up and run.

Запуск Apache 2.4 с модулем 1С внутри Docker контейнера

Про Apache и про Linux слышали, наверное, все. А вот про Docker пока нет, но он сильно набирает популярность последнее время и не зря. Поделюсь своим опытом и дам пошаговую инструкцию настройки веб-сервера Apache с модулем 1С внутри Docker контейнера на Linux хосте. При этом сам сервер 1С может находиться совсем на другой машине и на другой операционной системе

Это не важно, главное чтобы Apache смог достучаться до сервера 1С по TCP. В статье дам подробное пояснение по каждой используемой команде со ссылками на документацию по Docker, чтобы не создавалось ощущение непонятной магии

Также прилагаю git репозиторий с описанием всей конфигурации, можете попробовать развернуть у себя буквально за 10 минут.

Анализ качества кода в EDT

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

Мы искали какое-то решение и нашли специальный плагин для EDT https://github.com/DoublesunRUS/ru.capralow.dt.bslls.validator, который использует BSL Language Server – те диагностики, которые используются в 1C (BSL) Community Plugin. Этот плагин сделал Александр Капралов, исходники плагина опубликованы на GitHub.

Этот плагин наряду со стандартной проверкой для EDT показывает вам пул ошибок, которые потом всплывут в SonarQube.

Плагины в EDT ставятся через пункт меню Справка – Установить новое ПО.

Здесь мы должны выбрать сайт Александра Капралова http://capralow.ru/edt/bslls.validator/latest/. Выбираем этот адрес, и устанавливаем плагин. И теперь, если мы зайдем в EDT, мы можем в нем увидеть эти диагностики в режиме разработки модуля.

Давайте посмотрим в списке ошибок SonarQube какой-нибудь дефект. Например, дефект в общем модуле МенеджерОборудованияВызовСервера.

Заходим в это место кода в EDT и видим, что он пишет ровно то же самое, что потом напишет SonarQube. Это очень удобно – сразу такие ошибки исправлять в процессе разработки, не доводить до греха.

В следующих частях продолжим рассказывать:

про тестирование;
и про написание сборочной линии для проекта на Jenkins и в зависимости от результата – создания cf-файла релиза или отправки сообщения об ошибках на email.

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2019 Inception. Больше статей можно прочитать здесь.

Инсталляция Jenkins

Как было сказано выше, мы установим openjava, сервис Jenkins и завершим развертывания на портале. Итого, 3 этапа.

1. Установка openjdk

Выполняем команду:

apt-get install default-jdk

Выбираем реализацию java по умолчанию с помощью утилиты update-alternatives:

update-alternatives —config java

Скорее всего, мы увидим сообщение:

There is only one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/java-11-openjdk-amd64/bin/java
Nothing to configure.

Это значит, что в системе установлена только одна реализация java. Но если их несколько, на запрос:

Selection Command
————————————————
*+ 1 java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.9.11-0.el8_2.x86_64/bin/java)

… выбираем вариант с подходящей версией, например, последней:

Enter to keep the current selection, or type selection number: 1

Готово. Смотрим версию установленной java:

java -version

Мы должны увидеть что-то на подобие:

openjdk version «11.0.10» 2021-01-19
OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubuntu1.20.04)
OpenJDK 64-Bit Server VM (build 11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode, sharing)

2. Установка Jenkins

Для установки сервиса Jenkins добавляем репозиторий:

vi /etc/apt/sources.list.d/jenkins.list

deb https://pkg.jenkins.io/debian-stable binary/

Импортируем публичный ключ для подключения к репозиторию:

wget -q -O — https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add —

Обновляем список пакетов:

apt-get update

Устанавливаем jenkins:

apt-get install jenkins

Разрешаем автозапуск сервиса:

systemctl enable jenkins

3. Завершение установки

Открываем браузер и переходим по адресу http://<IP-адреса сервера Jenkins>:8080 — откроется окно «Unlock Jenkins». В нем будет путь до файла, в котором нужно взять парольную фразу для разблокировки портала:

И так, на сервере вводим команду:

cat /var/lib/jenkins/secrets/initialAdminPassword

* где /var/lib/jenkins/secrets/initialAdminPassword — полный путь до файла, который отображен на стартовой странице установки.

Мы должны увидеть что-то на подобие:

# cat /var/lib/jenkins/secrets/initialAdminPassword
35635dce8b014707a2ec90937763cfe3

Используем данный пароль и вставляем его в поле Administrator password:

В следующем окне выбираем вариант установки плагинов — рекомендованные или по выбору:

* если мы не слишком хорошо знакомы с продуктом, выбираем рекомендованные плагины.

Начнется процесс развертывания Jenkins:

После создаем учетную запись для администратора:

На последней странице мы можем задать URL-адрес для нашего портала (или оставить IP-адрес):

Установка завершена.

Multibranch Pipeline

A Multibranch Pipeline is a job type that scans all branches in a given repository for a Jenkinsfile. It automatically creates jobs for each branch inside a folder and executes Jenkinsfile for each job. This is useful in common branching workflows such as Git Flow which has naming conventions for branches, such as the prefix for feature-branches.

Go to Manage Jenkins > Manage Plugins and install the plugin (without restart)
Click New Item, name it , select Multibranch Pipeline as the type and click OK
At Branch Sources click Add source, Git
- Project Repository: https://bitbucket.org/your-account/your-repo.git
- Set credentials if this is not a public repository
Click Save

The plugin will automatically scan the repository for branches and create jobs; refresh the page if necessary to reveal them. After creating the jobs they will be automatically executed.

When one of the jobs fails, this could again be a script call signature that should be whitelisted. Go to /scriptApproval/ again to approvie the signature.

Настройка SonarQube

После того как вы отредактировали файл sonar.properties, можно запустить сам SonarQube.

Для его запуска в каталоге bin у нас есть соответствующие папки под каждую из поддерживаемых операционных систем – для Linux, Mac и Windows. Допустим, у нас здесь стоит 64-битный Windows. Заходим сюда:

здесь есть батник StartSonar, которым можно запустить SonarQube из командной строки;
можно поставить SonarQube как сервис, чтобы он крутился на сервере как служба:
- файл InstallNTService.bat создает сервис SonarQube в списке сервисов;
- UninstallNTService.bat – удаляет;
- StartNTService.bat запускает сервис;
- а файл StopNTService.bat – останавливает.

Проще всего запускать эти батники из командной строки, потому что, если мы запустим батник двойным кликом в проводнике и будут какие-то ошибки, вы можете просто не успеть их увидеть.

После того как мы запустим сервис, в службах служба появится SonarQube – вы можете уже им пользоваться.

Чтобы проверить, что SonarQube запустился, нужно в браузере написать URL, на котором поднят SonarQube, указать порт (по умолчанию 9000), и в конце нужно написать maintetance. Это, по сути, проверка работоспособности – здесь он показывает, что SonarQube активен, все системы в норме. И дальше вы уже можете приступить к настройке внутри самого SonarQube, посмотреть, как оно работает.

Что здесь важно? Когда вы только устанавливаете SonarQube из коробки, тут есть только один пользователь admin и пароль тоже admin. Этот пароль лучше потом поменять, потому что очень много прав у админа, не стоит всем эти права раздавать

SonarQube – это платформа, которая расширяется на разные языки программирования с помощью плагинов. Плагины есть бесплатные, а есть платные. Есть дорогие, а есть не очень дорогие.

Плагин можно поставить через магазин – Администрирование – Магазин. Здесь есть куча различных плагинов – часть из них уже установлены в коробочной версии SonarQube (например, самые распространенные – для Java, для C).

Первым делом мы поставим нужные нам плагины:

1C (BSL) Community Plugin – это бесплатный плагин, который использует диагностику кода с помощью BSL Language Server. Есть платные варианты, но они обычно стоят очень много денег, а для «попробовать» (понять, насколько это вообще нужно) нам вполне хватает бесплатного.
Russian Pack – для перевода самого SonarQube на русский язык. Здесь еще не полностью все переведено, но большинство основных команд уже на русском.

Некоторые плагины поставляются разработчиками не через магазин, а отдельно в виде jar-файла. Если чего-то в магазине нет, в папке самого SonarQube есть папка extensions, где в папке plugins находятся исполняемые файлы с расширением jar – это все те плагины, которые у нас сейчас установлены. Поставляемый jar-файл плагина можно просто сюда скопировать, SonarQube это увидит, покажет, что появился новый плагин, его нужно будет перезапустить и потом можно будет этим пользоваться.

Проблемы, вызванные кодировкой

Эта проблема может быть вызвана кодированием.

Параметр sonar.sourceEncoding:

По умолчанию используется системная кодировка.

Его можно добавить в опции сонара-сканера в файле конфигурации gitlab-ci, Чтобы использовать указанную кодировку при обнаружении.

Если указанная кодировка недействительна, вам необходимо скомпилировать изображение sonar-scanner-cli, чтобы создать новый образ контейнера:

Скомпилируйте Dockerfile.

Затем отмените ранее зарегистрированный раннер в контейнере gitlab-runner. Поскольку мы зарегистрировали только одного участника, напрямуюПараметр отменяет всех зарегистрированных участников.

Затем перерегистрируйте бегунов，。

Затем в проекте gitlab。

Наконец, сохраните и отправьте .gitlab-ci.yml, чтобы решить эту проблему.

Docker Compose for SonarQube

Check UID of the default user in the SonarQube Docker image:

root@jenkins-dev:/opt/sonarqube# docker run -ti sonarqube iduid=999(sonarqube) gid=999(sonarqube) groups=999(sonarqube)

Create directories to keep SonarQube’s data:

root@jenkins-dev:~# mkdir -p /data/sonarqube/{conf,logs,temp,data,extensions,bundled_plugins,postgresql,postgresql_data}

Create a new user and change those directories owner:

root@jenkins-dev:~# adduser sonarquberoot@jenkins-dev:~# usermod -aG docker sonarquberoot@jenkins-dev:~# chown -R sonarqube:sonarqube /data/sonarqube/

Find a UID of the user created above:

root@jenkins-dev:/opt/sonarqube# id sonarqubeuid=1004(sonarqube) gid=1004(sonarqube) groups=1004(sonarqube),999(docker)

Create a Docker Compose file using the UID in :

version: "3"networks:  sonarnet:    driver: bridgeservices:  sonarqube:    // use UID here    user: 1004:1004    image: sonarqube    ports:      - "9000:9000"    networks:      - sonarnet    environment:      - sonar.jdbc.url=jdbc:postgresql://db:5432/sonar    volumes:      - /data/sonarqube/conf:/opt/sonarqube/conf      - /data/sonarqube/logs:/opt/sonarqube/logs      - /data/sonarqube/temp:/opt/sonarqube/temp      - /data/sonarqube/data:/opt/sonarqube/data      - /data/sonarqube/extensions:/opt/sonarqube/extensions      - /data/sonarqube/bundled_plugins:/opt/sonarqube/lib/bundled-plugins  db:    image: postgres    networks:      - sonarnet    environment:      - POSTGRES_USER=sonar      - POSTGRES_PASSWORD=sonar    volumes:      - /data/sonarqube/postgresql:/var/lib/postgresql      - /data/sonarqube/postgresql_data:/var/lib/postgresql/data

Check it:

Создание и настойка задания

На главной странице Jenkins кликаем по Создать Item:

Даем название нашей задаче и ниже выбираем Pipeline:

Нажимаем кнопку OK:

Прокручиваем страницу вниз до подраздела «Pipeline» — сюда мы пишем скрипт на Groovy:

Также у нас есть возможность использовать репозиторий Git в качестве источника файла Jenkinsfile, выбрав в подразделе «Definition» Pipeline script from SCM и Git:

… но мы в данной инструкции будем рассматривать написание кода напрямую в Jenkins.

Для начала, напишем приветствие:

pipeline {
agent any
stages {
stage(‘Hello’) {
steps {
echo ‘Hello World’
}
}
}
}

Существует 2 способа написания pipeline — скриптовый и декларативный. В нашем примере используется последний. Благодаря строгому синтаксису, он проще читается — в декларативном пайплайне обязательно должны быть:

Директива pipeline. В нее мы оборачиваем наш код.
Определение агента. В нашем примере пока не задан конкретный (agent any), но ниже мы рассмотрим запуск конвейера в docker.
Необходима директива stages, в которой, в свою очередь, определены стадии (stage).
Обязательно указываем steps, в котором и будет наш код.

А также:

Экранирование некоторых символов можно сделать с помощью обратного слеша — \
Блок текста, например для его написания в несколько строк, можно обернуть в три одинарные кавычки — »’
Оставить комментарий на одну строку можно двумя прямыми слешами — //
Блок комментария делаем так — /* комментарий */

И нажимаем Сохранить:

* наш скрипт на Groovy будет сохранен в так называемый Jenkinsfile — это файл, в котором мы описываем этапы выполнения нашего задания с использованием pipeline.

Нас перекинет на страницу задания — слева кликаем по Собрать сейчас:

Конвейер немного поработает и выдаст результат, состоящий из одного шага:

Созданное задание работает — попробуем его усложнить.

Jenkins Docker Compose

Now time to add SonarQube to the Jenkins Docker Compose file (although can be used as a dedicated service) — move SonarQube and PostgreSQL to this file:

version: '3'networks: jenkins:services:  jenkins:    user: root    image: jenkins/jenkins:2.164.3    networks:      - jenkins    ports:      - '8080:8080'      - '50000:50000'    volumes:      - /data/jenkins:/var/lib/jenkins      - /var/run/docker.sock:/var/run/docker.sock      - /usr/bin/docker:/usr/bin/docker      - /usr/lib/x86_64-linux-gnu/libltdl.so.7:/usr/lib/x86_64-linux-gnu/libltdl.so.7    environment:      - JENKINS_HOME=/var/lib/jenkins      - JAVA_OPTS=-Duser.timezone=Europe/Kiev      - JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Dhudson.model.DirectoryBrowserSupport.CSP=\"default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' 'unsafe-inline' data:;\""    logging:      driver: "journald"  sonarqube:    user: 1004:1004    image: sonarqube    ports:      - "9000:9000"    networks:      - jenkins    environment:      - sonar.jdbc.url=jdbc:postgresql://db:5432/sonar    volumes:      - /data/sonarqube/conf:/opt/sonarqube/conf      - /data/sonarqube/logs:/opt/sonarqube/logs      - /data/sonarqube/temp:/opt/sonarqube/temp      - /data/sonarqube/data:/opt/sonarqube/data      - /data/sonarqube/extensions:/opt/sonarqube/extensions      - /data/sonarqube/bundled_plugins:/opt/sonarqube/lib/bundled-plugins    logging:      driver: "journald"  db:    image: postgres    networks:      - jenkins    environment:      - POSTGRES_USER=sonar      - POSTGRES_PASSWORD=sonar    volumes:      - /data/sonarqube/postgresql:/var/lib/postgresql      - /data/sonarqube/postgresql_data:/var/lib/postgresql/data    logging:      driver: "journald"

Restart Jenkins service (see the Linux: systemd сервис для Docker Compose post (Rus)):

root@jenkins-dev:/opt/jenkins# systemctl restart jenkins

Check containers:

root@jenkins-dev:/home/admin# docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESfc2662391c45 sonarqube “./bin/run.sh” 48 seconds ago Up 46 seconds 0.0.0.0:9000->9000/tcp jenkins_sonarqube_13ac2bb5f0e87 postgres “docker-entrypoint.s…” 48 seconds ago Up 46 seconds 5432/tcp jenkins_db_1113496304b0f jenkins/jenkins:2.164.3 “/sbin/tini — /usr/…” 48 seconds ago Up 46 seconds 0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp jenkins_jenkins_1

Go to the Sonar’s web-interface:

Sonar Scanner: 0 files indexed

But why 0 scanned?

Something wrong with directories mapping from Jenkins to its Scanner container.

Let’s try to set and explicitly:

...    stage('SonarTests') {        docker.image('newtmitch/sonar-scanner').inside('-v /var/run/docker.sock:/var/run/docker.sock --entrypoint="" --net jenkins_jenkins') {            sh "/usr/local/bin/sonar-scanner -Dsonar.host.url=http://sonarqube:9000 -Dsonar.sources=/var/lib/jenkins/workspace/SonarTest -Dsonar.projectBaseDir=/var/lib/jenkins/workspace/SonarTest -Dsonar.projectKey=ProjectName -Dsonar.login=91a691e7c91154d3fee69a05a8fa6e2b10bc82a6 -Dsonar.verbose=true"        }    }

Run it:

Works.

And again — results in the SonarQube:

Actually — that’s all, now need to make all of this cleaner.

So the issue of the files looks like appear because Jenkins Docker plugin maps a current working dir to a container with the same name and then sets it as a :

While tries to find it in the default Based dir:

Let’s try to set with the «» value, i.e. — current directory.

Now the script looks like next:

node {    stage('Clone repo') {        git branch: "develop", url: "git@github.com:example-dev/example-me.git", credentialsId: "jenkins-github"    }    stage('SonarTests') {        docker.image('newtmitch/sonar-scanner').inside('-v /var/run/docker.sock:/var/run/docker.sock --entrypoint="" --net jenkins_jenkins') {            sh "/usr/local/bin/sonar-scanner -Dsonar.host.url=http://sonarqube:9000 -Dsonar.projectBaseDir=. -Dsonar.projectKey=ProjectName -Dsonar.login=91a691e7c91154d3fee69a05a8fa6e2b10bc82a6"        }    }}

Run it:

A project’s settings can be moved to a file in a project’s Github repository root:

sonar.host.url=http://sonarqube:9000sonar.projectBaseDir=.sonar.projectKey=ProjectNamesonar.login=91a691e7c91154d3fee69a05a8fa6e2b10bc82a6

And update our script to removed all parameters — Scanner will look for the to use its settings:

node {    stage('Clone repo') {        git branch: "develop", url: "git@github.com:example-dev/example-me.git", credentialsId: "jenkins-github"    }    stage('SonarTests') {        docker.image('newtmitch/sonar-scanner').inside('-v /var/run/docker.sock:/var/run/docker.sock --entrypoint="" --net jenkins_jenkins') {            sh "/usr/local/bin/sonar-scanner"        }    }}

Done.

Тестирование конвейера

Чтобы увидеть весь конвейер в действии, снова измените файл index.js в разветвлении репозитория GitHub и нажмите кнопку Commit changes (Зафиксировать изменения). Новое задание запускается Jenkins в зависимости от объекта webhook для GitHub. Создание образа Docker и запуск вашего приложения в новом контейнере занимает несколько секунд.

При необходимости снова получите общедоступный IP-адрес виртуальной машины:

Откройте веб-браузер и введите . Приложение Node.js отображается и отражает последние фиксации в разветвлении GitHub следующим образом:

Теперь внесите другое изменение в файл index.js в GitHub и зафиксируйте изменение. Подождите несколько секунд, пока завершится задание в Jenkins, а затем обновите веб-браузер, чтобы увидеть измененную версию приложения, выполняющегося в новом контейнере, следующим образом:

Analyzing a Java project with Maven or Gradle

Global Configuration

Log into Jenkins as an administrator and go to Manage Jenkins > Configure System
Scroll to the SonarQube servers section and check Enable injection of SonarQube server configuration as build environment variables

Job Configuration

Configure the project, and go to the Build Environment section.
Enable Prepare SonarScanner environment to allow the injection of SonarQube server values into this particular job. If multiple SonarQube instances are configured, you will be able to choose which one to use.
Once the environment variables are available, use them in a standard Maven build step (Invoke top-level Maven targets) by setting the Goals to include, or a standard Gradle build step (Invoke Gradle script) by setting the Tasks to execute.

Maven goal:

Gradle task:

In both cases, launching your analysis may require authentication. In that case, make sure that the Global Configuration defines a valid SonarQube token.

Настройка оповещений

Теперь – еще один момент. Мы хотели бы еще, когда у нас прошла сборка, чтобы нам куда-то прилетало оповещение о том, что что-то произошло – появились какие-то новые ошибки. Это настраивается в несколько этапов.

Важный момент – в качестве Server base URL здесь нужно указать тот IP, на котором у вас находится SonarQube. Это нужно, чтобы гиперссылки в письме ссылались на правильный сервер (по умолчанию он всегда будет отправлять на localhost).

Например, вам придет сообщение, что прошел новый анализ, в новой версии появилось 55 ошибок – хотите их посмотреть? И чтобы к этим ошибкам перейти прямо из письма, вам нужно здесь указать, где у вас находится SonarQube.

После того как вы настроили почту, можно послать себе тестовое письмо и посмотреть, как оно будет выглядеть.

И дальше уже каждый пользователь сам себе настраивает те уведомления, которые он хочет получать. Для этого он заходит в Пользователь – Мой аккаунт – закладка Оповещения.

Здесь есть различные типы событий, о которых нужно оповещать – мы можем указать, что хотим получать все оповещения.

Также мы можем настроить оповещения в рамках каждого проекта.

Например, в рамках проекта Conference мы хотим видеть оповещения только по изменениям в замечаниях, назначенных мне. Тогда для проекта Conference будет своя настройка оповещений.

К сожалению, нет штатной возможности назначать эти оповещения другому пользователю – пока что приходится каждому самому для себя назначать. Возможно, позже какой-то плагин для этого появится. Пока что каждый настраивает сам для себя и, если при анализе были обнаружены проблемы, о которых вы хотите, чтобы вас уведомляли, вам придет напоминалка по почте.

Использование агента docker

Переходим к настройке нашего задания или создаем новое и приводим Groovy-код к такому виду:

pipeline {
agent { docker { image ‘python:latest’ } }
stages {
stage(‘Подготовка’) {
steps {
sh «python —version»
}
}
stage(‘Сборка’) {
steps {
echo ‘Выполняем команды для сборки’
}
}
stage(‘Тестирование’) {
steps {
echo ‘Тестируем нашу сборку’
}
}
stage(‘Развертывание’) {
steps {
echo ‘Переносим код в рабочую среду или создаем артефакт’
}
}
}
}

* обратите внимание, мы изменили агента на docker с указанием образа, в котором будет выполняться обработка — в данном примере, с помощью python (последней версии). Также мы добавили этап Подготовка, в котором просто выведем на экран версию python

Первый запуск будет выполняться долго, так как необходимо будет загрузить образ. В конечном итоге, мы должны получить, примерно, следующую картину:

Для подробного просмотра хода процесса (или решения проблем в случае их возникновения), кликаем по стрелке справа от названия задания и переходим к сборке:

Переходим к консоли:

Если задание выполнено успешно, среди логов мы должны увидеть версию используемого в контейнере Docker python:

Настройка Jenkins

Чтобы получить доступ к экземпляру Jenkins, получите общедоступный IP-адрес виртуальной машины:

В целях безопасности для запуска установки Jenkins необходимо ввести первоначальный пароль администратора, хранящийся в текстовом файле на виртуальной машине. Используйте общедоступный IP-адрес, полученный на предыдущем шаге, чтобы настроить подключение SSH для виртуальной машины:

С помощью команды проверьте, запущен ли сервер Jenkins:

Просмотрите для установки Jenkins и скопируйте его:

Если файл еще не доступен, подождите несколько минут, пока файл cloud-init не завершит установку Jenkins и Docker.

Теперь откройте браузер и перейдите к . Выполните начальную настройку Jenkins следующим образом:

Щелкните Select plugins to install (Выбрать подключаемые модули для установки).
Выполните поиск по слову GitHub в текстовом поле вверху. Установите флажок для GitHub, а затем выберите Установить.
Создайте первого администратора. Введите имя пользователя, например admin, а затем укажите безопасный пароль. Наконец введите полное имя и адрес электронной почты.
Выберите Сохранить и завершить.
Когда настройка Jenkins будет завершена, щелкните Start using Jenkins
Если веб-браузере отображает пустую страницу при запуске Jenkins, перезапустите службу Jenkins. В сеансе SSH введите sudo service jenkins restart, а затем обновите веб-браузера.

(Начать работу с Jenkins).
При необходимости войдите в Jenkins, введя созданные имя пользователя и пароль.

Using a Jenkins pipeline

We provide a block that allows you to select the SonarQube server you want to interact with. Connection details you have configured in Jenkins global configuration will be automatically passed to the scanner.

If needed you can override the if you don’t want to use the one defined in global configuration (for example if you define credentials at folder level).

If you only need the SonarQube environment variables to be expanded in the build context then you can override the flag.

Here are some examples for every scanner, assuming you run on Unix slaves and you have configured a server named «My SonarQube Server» as well as required tools. If you run on Windows slaves, just replace with .

SonarScanner:

SonarScanner for Gradle:

SonarScanner for Maven:

SonarScanner for .NET:

Итоги перевода тестирования на Docker

Как в итоге получилось?

Мой образ – мои правила. Теперь каждая команда могла подготовить свой собственный образ с нужными ей библиотеками. И никто другой в него вмешиваться не сможет.
Можно выполнять операции параллельно – контейнер занимает мало места, и, например, конвертацию из формата EDT и CF мы теперь можем собирать параллельно. Раньше в один поток запускалось, потому что они как-то конфликтовали между собой даже на разных сеансах.
Уменьшили потребление памяти. Некоторые тесты занимают 400 мегабайт, благодаря чему, например, на той же машине в 2 гигабайта мы можем слить их в пять потоков вместо одного.
И теперь мониторить надо всего единственный наш сервер, на котором мы все запускаем, а не восемь виртуальных машин, которые были до этого.
Наконец, начали тестировать наши приложения под Linux. Это достаточно интересно – находятся неожиданные артефакты.
Ну и прокачка Hard-скиллов. Если раньше для работы с Docker-ом мы просто скачивали что-то с GitHub и запускали: «Не работает – ну и ладно», то теперь пришлось разобраться, как же он работает.

Из негативных итогов:

Памяти все равно мало. То есть у нас Docker-хост был на 8 гигабайт, и иногда на нем место заканчивается быстро – нужно выделять больше.
VNC так и не пригодилось, потому что там надо аккуратно порты пробрасывать, поскольку машина одна, а контейнеров много. И VNC мы так в итоге и не пользовались.
И мы не смогли запустить Docker-compose. Можно собрать «матрешку» из сервисов, которые вам нужны – например, если вы хотите монтировать внешнее API. Но такие «матрешки» мы запустить не смогли.