Как настроить оболочку shell и как устранить вывод каракулей спецсимволов в консоли

newman run https://api.postman.com/collections/key...

-Dfile.encoding=UTF8

Одной из важнейших составляющих конвейера непрерывной интеграции и непрерывного развертывания (CI/CD) является непрерывное тестирование, которое очень сложно автоматизировать.  Jenkins — это популярный инструмент с открытым исходным кодом для непрерывной интеграции (CI), который используется для автоматического тестирования и развертывания вашего кода.

Одним из преимуществ Jenkins является его гибкость. Однако это также может быть и его недостатком. Решение о том, какие методологии, плагины и инструменты использовать в паре с Jenkins, может оказаться непростым. В этой статье вы узнаете о том, как лучше всего использовать Jenkins и как его настроить.

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Jenkins – это сервер автоматизации, который можно использовать для управления всеми этапами CI/CD. Благодаря поддержке множества тестовых фреймворков, плагинов и инструментов автоматизации, Jenkins также можно использовать для разработки и запуска автоматизированных тестов. Он выполняет тесты, а затем собирает информацию о найденных сбоях и ошибках.

:/>  Не могу получить пароли от wifi с помощью powershell

У Jenkins полностью открытый исходный код, и он очень легко настраивается. У него есть удобный графический интерфейс для управления всеми процессами. Кроме того, его можно интегрировать с современными программами для совместной работы, такими как Microsoft Teams, Asana и Slack.

С помощью Jenkins вы можете планировать тесты (по времени) или запускать их по какому-либо условию, например, при успешном завершении сборки. Он также совместим со множеством инструментов управления исходным кодом и контроля версий, таких как Git, Github, и Azure DevOps Team Foundation.

Это лишь некоторые из возможностей автоматизации тестирования с помощью Jenkins.

Внедрение автоматизации тестирования с помощью Jenkins

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

• У вас достаточно места на жестком диске и не менее 256 МБ оперативной памяти.
• В вашей локальной системе установлен и настроен Maven.
• OpenJDK JDK 17 (64 бит).
• Git установлен локально.
• Репозиторий GitHub с хотя бы одним проектом.

В этом туториале вы будете использовать плагин Sauce Labs для внедрения автоматизации тестирования в ваш CI/CD-конвейер на базе Jenkins. Этот плагин упрощает настройку тестов, размещенных в Sauce Lab.

Чтобы интегрировать Sauce Labs с Jenkins, вам понадобится следующее:

• Sauce Labs аккаунт.
• Имя пользователя аккаунта в Sauce Labs, ключ доступа и OnDemand URL.

Настройка Java для Jenkins

В следующих шагах показано, как настроить Jenkins для компьютеров с операционной системой Windows. Тем не менее, эти концепции в некоторой степени применимы и к другим операционным системам, отличным от Windows.

Сперва вам необходимо загрузить и установить Java Development Kit (JDK). Как уже говорилось ранее, Jenkins совместим только с 64-битными версиями JDK 11 и 17.

Затем нужно установить необходимые переменные окружения.

Настройка и установка Jenkins для Windows

Затем воспользуйтесь официальной документацией Jenkins, чтобы настроить и установить его на вашем компьютере с Windows.

Запуск и использование Jenkins

Чтобы использовать Jenkins, запустите ваш веб-браузер и перейдите по следующему адресу: http://localhost:8080/.

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

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

После успешной загрузки вы попадете на экран настройки, где сможете добавить плагины. Если вы впервые используете Jenkins, нажмите на Install suggested plugins. Вы можете заметить, что Git является одним из предложенных плагинов, который понадобится вам позже для управления версиями.

После завершения установки Jenkins попросит вас создать первого пользователя-администратора. После заполнения формы нажмите на Сохранить и продолжить:

Вам будет предложено настроить URL-адрес Jenkins; однако оставьте его как есть и выберите Сохранить и завершить. После нажатия на кнопку Start using Jenkins вы сможете настроить и интегрировать Git с Jenkins.

Добавление плагина Sauce Labs OnDemand в Jenkins

После того, как Jenkins будет готов к использованию (в первый раз), он перенаправит вас на панель управления, которая будет на главной странице.

Выберите Manage Jenkins на панели слева:

Далее выберите Manage Plugins:

Далее нажмите на Available plugins на левой боковой панели; затем введите “Sauce OnDemand” в строку поиска. В списке результатов установите флажок напротив Sauce OnDemand и выберите Install without restart:

Перезапустите Jenkins после установки всех плагинов.

Создание учетных данных Sauce Labs

Обязательно сохраните имя пользователя, ключ доступа и OnDemand URL.

После повторного входа в систему выберите Manage Jenkins на левой боковой панели. Затем прокрутите страницу вниз до раздела Security и нажмите на Manage Credentials:

Выберите System под Stores scoped to Jenkins:

И нажмите на ссылку Global credentials:

Затем нажмите на Add Credentials  и выберите “Sauce Labs”.

Оставьте параметр Scope как есть и введите имя пользователя и ключ доступа из вашей учетной записи Sauce Labs.

Выберите Sauce Data Center и оставьте ID пустым (Jenkins создаст его за вас). Поле Description также можно оставить пустым. Далее нажмите на Create:

Если вы вернетесь к экрану Credentials Management то увидите, что Jenkins создал учетную запись Sauce Labs.

Создание теста

Это руководство содержит образец репозитория с простым примером на Java. Он использует Sauce Labs для перехода на сайт https://www.saucedemo.com и проверки его названия. Два наиболее важных файла в репозитории – это `pom.xml` и `test class` файл.

Так как тест выполняется с использованием Maven, в файле pom.xml содержится список всех необходимых зависимостей Sauce Labs и Selenium для правильной работы теста.

Склонируйте репозиторий и добавьте ваш URL OnDemand в эту часть кода:

/* * OnDemand URL found under User Settings in Account Settings * The following is just an example, add your own URL
*/
// URL url = new URL("<SAUCE_USERNAME>:<SAUCE_ACCESSKEY>@ondemand.eu-central-1.saucelabs.com:443/wd/hub");
URL url = new URL(ON_DEMAND); //Replace ON_DEMAND with your onDemand URL here or the test will not work 

Интеграция Git с Jenkins

После того, как вы создали свою учетную запись, вернитесь на панель управления и выберите Create a job в разделе Start building your software project:

Введите название вашего проекта в поле Item name field и выберите Freestyle Project . Затем нажмите на кнопку OK в нижней части экрана:

Jenkins потребует от вас ввести некоторые подробности о вашем проекте. Введите простое описание, например “Простой тестовый проект”; затем перейдите на вкладку Source Code Management  на левой панели:

Нажмите на кнопку Git, в результате чего откроется новая форма, в которой вам будет предложено добавить информацию о вашем Git-репозитории. Вставьте ссылку на ваш репозиторий GitHub в поле Repository URL . Затем нажмите на кнопку + Add, после чего откроется небольшое всплывающее окно Jenkins:

Оставьте поля Domain, Kind и Scope как есть, и введите имя пользователя GitHub и пароль в соответствующие поля. Затем прокрутите страницу вниз и нажмите на Add:

:/>  9 эффективных решений для восстановления отсутствующих функций Bluetooth в Центре уведомлений Windows 10

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

Прокрутите вниз до раздела Branches to build. Там вы увидите, что `/master` в настоящее время является значением по умолчанию. Удалите это значение, и тогда Jenkins будет вынужден сканировать все ветки в репозитории. Если вы хотите, чтобы Jenkins отслеживал только определенную ветку, вы можете добавить сюда ее относительный путь (например, `/main`).

Далее прокрутите страницу вниз до раздела Build Environment и установите флажок на Sauce Labs Support, в результате чего откроется новая форма. Оставьте поле Enable Sauce Connect неотмеченным и щёлкните по выпадающему списку Credentials, выбрав ваши учетные данные Sauce Labs из списка:

Далее щелкните на поле WebDriver. Появится выпадающее меню со списком различных браузеров. Выберите браузеры, которые вы планируете использовать для тестирования. В этом примере используется последняя версия Microsoft Edge для Windows 10:

Затем установите флажок  на Use latest version of selected browsers.

Оставьте все остальное как есть и прокрутите страницу вниз, пока не увидите раздел Build Steps.

Щелкните на Add build step и в выпадающем меню выберите Execute Windows batch command:

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

mvn dependency:resolve

Добавьте еще один шаг Execute Windows batch command, который будет использоваться для проверки правильности добавления ссылок. Для этого введите следующую команду в текстовую область шага сборки:

mvn test-compile

В последнем шаге мы запустим тест. Как и в предыдущих шагах, добавьте еще одну команду Windows batch execution и добавьте в текстовую область следующее:

mvn test

Раздел с шагами сборки должен выглядеть примерно так:

Теперь прокрутите страницу вниз и нажмите на Save. Это перенаправит вас на экран информации о конвейерах, где вы сможете запустить свой конвейер Jenkins, выполнить сборку и активировать тест. Нажмите на Build Now, чтобы запустить конвейер.

Щелкнув на сборку в разделе Build History, вы перейдете на экран свойств сборки.

На этом экране можно просмотреть все детали сборки. Лучший способ просмотреть детали каждого шага сборки – это экран Console Output:

На этом экране вы можете увидеть все команды, которые выполнял ваш тест. Вы также можете просмотреть видео, как тест проходит на сервере Sauce Labs. Кроме того, вы можете ознакомиться с логами:

Что касается Jenkins, то вы можете добавить какие- то конкретные действия после сборки, такие как создание отчетов или сборка мусора. Кроме того, вы можете добавить триггеры сборки, которые будут автоматически запускать конвейер за вас, позволяя выполнять более сложные автоматизированные тесты.

Заключение

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

Перевод статьи «How to Use Jenkins For Test Automation».

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

Вот несколько ссылок, где есть некоторая информация по этому вопросу:

Не забываем, что мне совершенно неизвестно как делать правильно. Универсального рецепта не нашлось, поэтому собираю своего Кракена на win-сервере(local).

Прежде всего, я отказался от слоя абстракции связанной с контейнеризацией. Прошу прощения, любители Docker, мне он пока не зашел. Отличная идея использовать контейнеры, но духоты предвижу и так с головой – лучше не усложнять “архитектуру” еще одним слоем. Оставим на лучшее время. Трезво оценив возможности своих познаний я понял, что слои из Groovy pipeline-скриптов, batch-скриптов предоставляют уже немаленький конвейерный ад.

Классическая разработка под MCU:

1. Внесение изменений в прошивку

2. Сборка прошивки (необходимо подготовленное рабочее окружение)

3. Подготовка артефактов сборки к публикации

4. Публикация прошивок на сервере

5. Ручное добавление прошивок на новых релизах при поставке их в составе комплекса ПО

Как я это вижу с CI/CD:

1. Синхронизация с Git

2. Внесение изменений в прошивку

3. Добавление тега текущей версии

4. Пуш в Git

Автоматизированная сборка и публикация:

Вижу тут некоторые плюсы:

• • Подготовка прошивок к публикации (подпись, правка, изменение имени)

  • Публикация на сервер

• Использование единого набора инструментов для сборки

• Снижение сложности входа для новых сотрудников (спорно, но все же в перспективе)

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

Да, я вполне понимаю, что подобная система даст наибольшую отдачу при использовании Make/CMake и контейнеров (для изолирования среды и работы с уже подготовленными средами). Но имеем, что имеем – переписывать весь ворох проектов ради своего интереса в нерабочее время, это выше моих сил.

Дальнейшее описание будет для системы контроля версий GitLab.

У них есть отличная документация по интеграции GitLab с Jenkins (https://docs.gitlab.com/ee/integration/jenkins.html), лучше делать по ней, а сюда лишь посматривать – вдруг чего будет интересного

Про Jenkins

Суть его – лишь скрипт-раннер и место хранения
Дженкинс может подхватывать веб-хуки с гитлаба и сам начинать выполнять скрипты
Лучше всего, опять же, почитать документацию – здесь будет лишь очень поверхностная информация

В Jenkins прописывается:

• git ссылка до проекта с кодом и/или определенной веткой

• Откуда брать файл со скриптом конфигурации дженкинса. В этом скрипте прописываются шаги и какие батники выполнить – достаточно просто.

То есть, практически вся работа у Jenkins будет стянуть сборку, собрать и запустить пару батников.

Есть два основных варианта использования Jenkins. Со свободной конфигурацией и Pipeline

В первую очередь, нажимаем создать Item (Item – это один проект для сборки)

Тут нужно вписать название задачи и выбрать тип

Далее нужно вписать ссылку на проект и данные авторизации

Триггеры сборки определяют по какому из событий будет выполнена задача

Свободная конфигурация позволяет настроить все шаги сборки через веб-GUI. Вот пример

Pipeline – более гибкая в настройке система, которая позволяет исполнять скрипт сборки при наступлении события-триггера. Шаги сборки определяет скрипт на языке Groovy. Триггеры сборки и git-авторизация остаются теми же для обеих систем.

Pipeline Script позволяет записать скрипт в окне в веб-GUI. Pipeline Script from SCM – скачивает и исполняет Groovy-скрипт(Jenkinsfile) напрямую из репозитория с проектом.

Обратите внимание, что имя файла-скрипта должно быть указано в Script Path

Шаги для настройки своего проекта

Скачал Jenkins с официального сайта. Запустил, установил, ничего сложного. Установил GitLab, Pipeline: Stage View, Pipeline, Folders, Credentials, CppCheck и еще пару плагинов – тут уж на ваш вкус. Перезапустил Jenkins.

Еще в Jenkins прописал глобальные переменные с особыми путями (IDE, cppcheck, папка с bat-файлами и т.д.)

Токен генерируется в GitLab и для него выставил доступ к API

В настройках GitLab-проекта для сборки в settings->integrations включил Jenkins CL

Если нет Jenkins CL, то во вкладке settings->webhooks можно очень похожим образом настроить все тоже самое, с небольшой разницей в степени интеграции Jenkins и GitLab.

Jenkins URL: http://MY_PC_IP:8080/

Project Name: TEST_BUILDER (Должно совпадать с именем подготовленного задания на Jenkins)

На Jenkins создал Item Pipeline с настройкой Pipeline Script from SCM.

Теперь можно запускать Jenkinsfile из проекта на git.

Вот и все. При пуше в репозиторий с тегом, будет проведена сборка проекта согласно скрипту Jenkinsfile. Артефакты сборки можно будет закинуть на файловый сервер/другой репозиторий с помощью .bat файлов.

Вот так выглядит пайплайн сборки проекта:

Справа на графике видно, что есть замечания от cppcheck – смотрим:

Предупреждения кликабельны – можно посмотреть какой участок кода вызвал проблему прям в вебе:

Ну, и артефакты сборки пушатся на файловый сервер (Samba, smb-протокол) и на git, т.к. весят достаточно мало

Немного примеров и батников

Дженкинс по дефолту идет как локальная служба – нужно сделать его админом, иначе он не сможет вылезать в сетку

Для того, чтобы собрать проект через консоль, нужно использовать фичу, которая называется HeadlessBuild. Т.к. CubeIDE основана на Eclipse, то и команды очень похожие. Сама команда есть в примере файла build_stm_prj.bat. Как именно запускать stm32cubeide через терминал и какие параметры она принимает – можно узнать, выполнив такую команду:

\stm32cubeidec.exe -nosplash --launcher.suppressErrors -application org.eclipse.cdt.managedbuilder.core.headlessbuild -help

Пример команды сборки проекта для Atmel Studio:

if exist "build_log.txt" del "build_log.txt"
del /q AVR_PROJ\Release\
"E:\Program Files (x86)\Atmel\Atmel Studio 6.2\atmelstudio.exe" AVR_PROJ.atsln /rebuild Release /out build_log.txt
type build_log.txt

def RESULT_FILE_NAME
def TAGS_VERSION
pipeline{ agent any environment{ PROJ_NAME = "test_prj" PROJ_DIR = "test_prj" PROJ_ARTIFACTS_TYPE = "srec" PROJ_SOURCES = "${PROJ_DIR}\\Core\\Src" PROJ_ARTIFACTS_DIR = "${PROJ_DIR}\\Release" PROJ_ARTIFACTS_TYPE = "srec" SERVER_ARTIFACTS_DIR = "${FILE_SERVER_ADDR}\\FW_Folder" GITLAB_ARTIFACTS_DIR = "test_prj1" GITLAB_TARGET_NAME = "test_fw.${PROJ_ARTIFACTS_TYPE}" } stages{ stage('Check CPP'){ steps{ bat "${CPP_CHECK} ${PROJ_SOURCES} 2> cppcheck-result.xml" publishCppcheck pattern:'cppcheck-result.xml' } } stage('Unit tests'){ steps{ updateGitlabCommitStatus name: 'test', state: 'pending' dir("${PROJ_DIR}"){ bat "${CEEDLING}" } updateGitlabCommitStatus name: 'test', state: 'success' } } stage('Building'){ steps{ updateGitlabCommitStatus name: 'build', state: 'pending' bat "${BAT_TOOLS}\\build_stm_prj.bat ${WORKSPACE} ${PROJ_NAME}" updateGitlabCommitStatus name: 'build', state: 'success' } } stage('Publish Artifact'){ steps{ updateGitlabCommitStatus name: 'Artifact publication', state: 'pending' script { TAGS_VERSION = getCommandOutput("${BAT_TOOLS}\\get_tag.bat ${WORKSPACE}") echo "Tags is ${TAGS_VERSION}" } bat "${BAT_TOOLS}\\publish_file_to_gitlab.bat ${WORKSPACE} ${PROJ_ARTIFACTS_DIR} ${PROJ_NAME} ${GITLAB_ARTIFACTS_DIR} ${GITLAB_TARGET_NAME} \"${GITLAB_ARTIFACTS_DIR} project updated to version ${TAGS_VERSION}\"" bat "${BAT_TOOLS}\\publish_file_to_server.bat ${WORKSPACE} ${PROJ_ARTIFACTS_DIR} ${PROJ_NAME} ${SERVER_ARTIFACTS_DIR}" updateGitlabCommitStatus name: 'Artifact publication', state: 'success' } } } post{ success{ echo "Build succes" } unsuccessful{ updateGitlabCommitStatus name: 'build', state: 'failed' updateGitlabCommitStatus name: 'Artifact publication', state: 'failed' echo "ouhh..." } }
}
def getCommandOutput(cmd) { if (isUnix()){ return sh(returnStdout:true , script: '#!/bin/sh -e\n' + cmd).trim() } else{ stdout = bat(returnStdout:true , script: cmd).trim() result = stdout.readLines().drop(1).join(" ") return result }
}

Содержание файла get_tag.bat:

@echo off
set work_dir=%1
cd /d %work_dir%
setlocal enableextensions
for /F "tokens=1-2 delims=." %%I in (' git describe --tags ^| grep -Eo "[0-9]+\.[0-9]+"') do ( set tag_main=%%I set tag_minor=%%J )
echo %tag_main% %tag_minor%

Содержание файла build_stm_prj.bat:

@echo off
set proj_dir=%1
set project=%2
echo %proj_dir%
echo %project%
cd /d "%proj_dir%"
if exist "C:\STM32CubeIDE_headlessBuilds" rd /q /s "C:\STM32CubeIDE_headlessBuilds"
C:\ST\STM32CubeIDE_1.3.0\STM32CubeIDE\stm32cubeidec.exe --launcher.suppressErrors -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data "C:\STM32CubeIDE_headlessBuilds" -import %project% -cleanBuild all

Содержание файла для публикации артефакта на gitlab – publish_file_to_gitlab.bat:

SetLocal EnableExtensions
set work_dir=%1
set firm_file_dir=%2
set firm_file_name=%3
set project_git_name=%4
set target_firm_file_name=%5
set commit_str=%6
cd /d %work_dir%
cd /d %firm_file_dir%
::forced delete folder
rd /q /s gitlab_fw_dir 2>nul
::change the ip to yours
git clone git@0.0.0.0:FW/gitlab_fw_dir.git
::create project folder if not exist
if not exist "gitlab_fw_dir\%project_git_name%\" mkdir "gitlab_fw_dir\%project_git_name%"
::delete prev fw if exist
if exist "gitlab_fw_dir\%project_git_name%\%target_firm_file_name%" del "gitlab_fw_dir\%project_git_name%\%target_firm_file_name%"
xcopy %firm_file_name% gitlab_fw_dir\%project_git_name%\%target_firm_file_name%* >NUL
cd /d gitlab_fw_dir
git add -A
git commit -a -m %commit_str% >nul
git push >nul
cd /d ..
::forced delete folder
rd /q /s gitlab_dir 2>nul
exit 0

Содержание файла publish_file_to_server.bat (добавлен человекочитаемый вывод лога git на сервер в виде файла Changelog.txt):

SetLocal EnableExtensions
set work_dir=%1
set firm_file_dir=%2
set firm_file_name=%3
set project_git_name=%4
set target_firm_file_name=%5
set commit_str=%6
cd /d %work_dir%
cd /d %firm_file_dir%
::forced delete folder
rd /q /s gitlab_fw_dir 2>nul
git clone git@0.0.0.0:FW/gitlab_fw_dir.git
::create project folder if not exist
if not exist "gitlab_fw_dir\%project_git_name%\" mkdir "gitlab_fw_dir\%project_git_name%"
::delete prev fw if exist
if exist "gitlab_fw_dir\%project_git_name%\%target_firm_file_name%" del "gitlab_fw_dir\%project_git_name%\%target_firm_file_name%"
xcopy %firm_file_name% gitlab_fw_dir\%project_git_name%\%target_firm_file_name%* >NUL
cd /d gitlab_fw_dir
git add -A
git commit -a -m %commit_str% >nul
git push >nul
cd /d ..
::forced delete folder
rd /q /s gitlab_dir 2>nul
exit 0

Весь ворох скриптов и сборка сильно упрощается, если у вас проекты сделаны на самописных Make/Cmake – файлах, а система сборки запускается на Linux-сервере. Тогда, уместным является использование Docker-контейнеров с настроенным окружением под каждый проект. Локальная разработка будет логично продолжена сборкой, тестированием и публикацией артефактов.

Про это на Конвеерум рассказывал Дмитрий Лисин (Третий Пин):

На этом завершаем небольшое знакомство с процессом непрерывной интеграции программного обеспечения для микроконтроллеров. Успешных разработок!

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Что чаще всего вы используете при разработке ПО на микроконтроллеры?

IDE от производителя чипа

IDE универсальное (Keil, Iar)

Clang/LLVM/GCC + самописные Makefile/Cmake + Блокнот/VSCode

Проголосовали 25 пользователей. Воздержались 5 пользователей.

Похожее:

Шпаргалка с командами для windows linux и mac os терминал virtual env и git Alt-коды для Windows Полезные заготовки вызова утилит командной строки Windows клавиша