TOC

Как настроить конвейеры непрерывной интеграции с Concourse CI в Ubuntu 16.04

Вступление

Concourse CI - это современная масштабируемая система непрерывной интеграции, предназначенная для автоматизации конвейеров тестирования с составным декларативным синтаксисом. В предыдущих руководствах мы https://www.digitalocean.com/community/tutorials/how-to-install-concourse-ci-on-ubuntu-16-04 установили Concourse на сервере Ubuntu 16.04] и https: // www.digitalocean.com/community/tutorials/how-to-secure-concourse-ci-with-ssl-using-nginx-on-ubuntu-16-04 обеспечивает защищенный веб-интерфейс с помощью SSL-сертификата Let’s Encrypt].

В этом руководстве мы продемонстрируем, как использовать Concourse для автоматического запуска набора тестов вашего проекта при внесении новых изменений в репозиторий. Для демонстрации мы настроим конвейер непрерывной интеграции для приложения «hello world», написанного с помощью Hapi.js, веб-платформы Node.js.

Чтобы убедиться, что процедуры сборки и тестирования всегда синхронизированы с кодом, с которым они связаны, мы добавим определения CI в сам репозиторий приложения. После этого мы будем использовать инструмент командной строки Concurse + fly + для загрузки конвейера в Concourse. Наконец, мы отправим наши изменения обратно в хранилище, чтобы сохранить их более надолго и запустить новый тест в новом рабочем процессе CI.

Предпосылки

Прежде чем начать, вам понадобится сервер Ubuntu 16.04 * с не менее 1 ГБ ОЗУ *. Выполните следующие руководства, чтобы настроить пользователя без полномочий root, установить и настроить Concourse, установить Nginx, получить сертификат TLS / SSL и настроить безопасный обратный прокси-сервер для веб-интерфейса Concourse. Вам понадобится * доменное имя *, указанное на вашем сервере Concourse, чтобы правильно его защитить:

В этом руководстве большая часть работы будет выполнена на вашем локальном компьютере, а не на сервере Concourse. Таким образом, вам также необходимо убедиться, что на вашем локальном компьютере доступно несколько инструментов. Вам понадобится текстовый редактор (некоторые примеры, которые вы можете найти в различных операционных системах: + nano +, + vim +, TextEdit, Sublime Text, Atom или Notepad) для создания и изменения файлов в хранилище. Вам также необходимо установить и настроить Git в локальной системе, что можно сделать, следуя нашим https://www.digitalocean.com/community/tutorials/contributing-to-open-source-getting-started-with- git [Содействие Open Source: Начало работы с Git].

После того, как вы настроили сервер Concourse и установили Git и текстовый редактор на свой локальный компьютер, продолжайте ниже.

Установка инструмента командной строки Fly локально

Когда мы установили Concourse на сервер в предварительных условиях, мы установили инструмент командной строки + fly + на сервер, чтобы мы могли управлять экземпляром Concourse из командной строки. Однако для ежедневного использования удобнее установить копию двоичного файла + fly + в вашей локальной системе, где доступны ваши обычные инструменты разработки и исходный код.

Чтобы получить локальную копию + fly +, соответствующую версии вашего сервера, посетите ваш экземпляр Concourse в веб-браузере:

https://

Если вы вышли из системы или у вас нет настроенного конвейера, в центре окна будут отображаться ссылки для загрузки + fly + для разных платформ:

изображение: https: //assets.digitalocean.com/articles/concourse_usage_1604/big_download_link.png [Зал для скачивания большой ссылки для скачивания]

Если вы вошли в систему и настроили конвейер, ссылки на скачивание для + fly + будут доступны в правом нижнем углу экрана:

изображение: https: //assets.digitalocean.com/articles/concourse_usage_1604/small_download_link.png [Небольшая ссылка для скачивания с конкурса]

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

Затем следуйте инструкциям для конкретной платформы, чтобы настроить + fly + в вашей локальной системе.

Linux или macOS

Если ваш локальный компьютер работает под управлением Linux или macOS, следуйте этим инструкциям после загрузки соответствующего двоичного файла.

Сначала отметьте загруженный двоичный файл как исполняемый. Предположим, что вы загрузили файл в каталог + ~ / Downloads +, поэтому при необходимости измените местоположение загрузки:

chmod +x ~/Downloads/fly

Затем установите двоичный файл в папку в вашем PATH, набрав:

sudo install ~/Downloads/fly /usr/local/bin

Вы можете проверить, доступен ли исполняемый файл, набрав:

fly --version
Output3.3.1

Если вы можете отобразить версию, + fly + был успешно установлен.

Windows

Если ваш локальный компьютер работает под управлением Windows, нажмите клавишу * Windows * на клавиатуре, введите * powershell * и нажмите * ENTER *.

В появившемся окне создайте папку + bin +, набрав:

mkdir bin

Затем переместите файл + fly.exe + из папки + Downloads в новую папку` + bin`, набрав:

mv Downloads/fly.exe bin

Убедитесь, что у вас уже есть профиль PowerShell:

Test-Path $profile

Если ответ + True +, у вас уже есть профиль.

Если ответ + False +, вам нужно создать его, набрав:

New-Item -path $profile -type file -force
Output
   Directory: C:\User\Sammy\Documents\WindowsPowerShell

Mode              LastWriteTime       Length Name
----              -------------       ------ ----
-a----       7/9/2017   5:46 PM            0 Microsoft.PowerShell_profile.ps1

Если у вас есть профиль, отредактируйте его в редакторе:

notepad.exe $profile

В окне редактора (которое будет пустым, если вам нужно было создать свой профиль), добавьте следующую строку:

Microsoft.PowerShell_profile.ps1

$env:path += ";C:\Users\Sammy\bin"

Сохраните и закройте файл, когда вы закончите.

Затем установите для политики выполнения значение «RemoteSigned» для текущего пользователя, чтобы разрешить PowerShell читать профиль:

Set-ExecutionPolicy -scope CurrentUser RemoteSigned

Наконец, создайте профиль PowerShell, набрав:

. $profile

Теперь вы можете вызывать исполняемый файл + fly.exe + из любого места. Проверьте это, напечатав бинарную версию:

fly.exe --version
Output3.3.1

В этом руководстве вам нужно будет заменить каждый экземпляр команды + fly + на + fly.exe + в соответствии с командой Windows.

Аутентификация с помощью Concourse Server

После установки + fly + войдите на удаленный сервер Concourse, чтобы вы могли локально управлять своей средой CI. Один двоичный файл + fly + может использоваться для связи и управления несколькими серверами Concourse, поэтому команда использует концепцию, называемую «цели», в качестве метки для идентификации сервера, на который вы хотите отправлять команды.

В этом руководстве мы используем * main * в качестве целевого имени для нашего сервера Concourse, но вы можете заменить любое желаемое имя. Введите доменное имя вашего сервера Concourse вместе со спецификацией протокола + https: // + после опции + -c +, чтобы указать местоположение вашего сервера:

fly -t main login -c https://

Вам будет предложено ввести имя пользователя и пароль, которые вы настроили в файле + / etc / concourse / web_environment + на сервере Concourse:

Outputlogging in to team 'main'

username: sammy
password:

target saved

После аутентификации инструмент + fly + создаст файл конфигурации под названием + ~ / .flyrc + для хранения ваших учетных данных для будущих команд.

Форкинг и клонирование репозитория примеров

Теперь, когда в вашей системе настроен + fly +, мы можем перейти к настройке репозитория, который мы будем использовать для демонстрации конвейеров Concourse.

В вашем веб-браузере перейдите на страницу FShello hapi »на GitHub, которую мы будем использовать в качестве нашего примера. Это приложение представляет собой простую программу «hello world» с несколькими модульными и интеграционными тестами, написанную с помощью Hapi.js, веб-инфраструктуры Node.js.

Поскольку этот пример используется для демонстрации множества систем непрерывной интеграции, вы можете заметить некоторые файлы, используемые для определения конвейеров для других систем. Для Concourse мы будем создавать конвейер непрерывной интеграции в нашем собственном форке репозитория.

Чтобы создать свой форк репозитория, войдите в GitHub и перейдите в project хранилище. Нажмите кнопку * Fork * в правом верхнем углу, чтобы сделать копию хранилища в вашей учетной записи:

изображение: https: //assets.digitalocean.com/articles/concourse_usage_1604/fork_repository.png [привет хапи, репозиторий вилок]

Если вы являетесь членом организации GitHub, вас могут спросить, куда вы хотите подключить репозиторий. После выбора учетной записи или организации копия репозитория будет добавлена ​​в вашу учетную запись.

Затем в терминале на локальном компьютере перейдите в домашний каталог:

cd $HOME

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

git clone [email protected]:/hello_hapi

В вашем домашнем каталоге будет создан новый каталог с именем + hello_hapi +. Введите новый каталог, чтобы начать:

cd hello_hapi

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

git checkout -b pipeline
OutputSwitched to a new branch 'pipeline'

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

Настройка процесса непрерывной интеграции для приложения

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

Набор тестов уже определен в каталоге с именем + test. Он включает в себя один модульный тест и два основных интеграционных теста. Команда для запуска тестов определена в файле + package.json под именем` + test` в объекте + script. В среде с установленными + npm + и Node.js вы можете запустить тесты, набрав + npm test + (после установки зависимостей проекта с помощью + npm install +). Это процедуры, которые нам нужно будет повторить в нашем конвейере.

Для начала создайте каталог с именем + ci + в репозитории для размещения ресурсов непрерывной интеграции для проекта. Мы также создадим две подкаталоги, названные + ci / tasks + и + ci / scripts +, чтобы хранить отдельные определения задач, на которые ссылается конвейер, и сценарии, которые эти задачи вызывают.

Создайте необходимую структуру каталогов, набрав:

mkdir -p ci/{tasks,scripts}

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

Определение трубопровода

Создайте и откройте файл с именем + pipeline.yml + в каталоге + ci + с помощью текстового редактора (в этом руководстве мы покажем редактор + nano +, но вы должны заменить текстовый редактор для вашей системы). Как указывает расширение, файлы конкурса определяются с использованием формата сериализации данных YAML:

nano ci/pipeline.yml

Теперь мы можем начать настройку нашего конвейера.

Определите тип ресурса кэша NPM

Внутри файла мы начнем с определения нового типа ресурса:

Ки / pipeline.yml

---
resource_types:
 - name: npm-cache
   type: docker-image
   source:
     repository: ymedlop/npm-cache-resource
     tag: latest

Чтобы отделить процессы в непрерывной интеграции от данных, проходящих через систему, Concourse выгружает всю информацию о состоянии в абстракции, называемые * resources *. Ресурсы - это внешние источники данных, которые Concourse может использовать для извлечения или передачи информации. Вот как все данные поступают в систему непрерывной интеграции и как все данные распределяются между заданиями. Concourse не предоставляет никакого механизма для хранения или передачи состояния внутри между заданиями.

Заголовок * resource_types * позволяет вам определять новые виды ресурсов, которые вы можете использовать в своем конвейере, такие как уведомления по электронной почте, интеграция с Twitter или RSS-каналы. Новый тип ресурса, который мы определяем, сообщает Concourse, как использовать npm-cache-resource, ресурс, предоставленный в виде образа Docker, который позволяет Concourse устанавливать зависимости проект Node.js и делиться ими между рабочими местами.

Определите ресурсы репозитория и кэширования

Далее нам нужно определить фактические ресурсы для конвейера:

Ки / pipeline.yml

. . .

resources:
 - name: hello_hapi
   type: git
   source: &repo-source
     uri: https://github.com//hello_hapi
     branch: master
 - name: dependency-cache
   type: npm-cache
   source:
     <<: *repo-source
     paths:
       - package.json

В этом разделе определяются два ресурса, которые требуются заданиям Concourse CI для выполнения своих задач. Concourse использует определения ресурсов для отслеживания изменений в вышестоящих системах и для понимания того, как использовать ресурсы в тех случаях, когда их требуют задания. По умолчанию Concourse проверяет каждый ресурс на наличие новых версий раз в минуту. Задания, для которых требуется ресурс с установленной опцией «триггер», автоматически запускают новую сборку, когда доступна новая версия.

Первый ресурс представляет ваш форк репозитория + hello_hapi + на GitHub. Строка «source» содержит YAML якорь с именем «repo-source», который обозначает элемент для будущей ссылки. Это позволяет нам включать содержимое элемента (определения «uri» и «branch») в другое место позже в документе.

Второй ресурс, называемый «кеш зависимостей», использует тип ресурса «npm-кеш», который мы определили для загрузки зависимостей проекта. В спецификации «source» этого ресурса мы используем строку + <<: * repo-source + для reference и extend элементы, на которые указывает якорь + & repo-source +. Это вставит параметры URI и ветви из нашего ресурса репозитория приложений в этот второй ресурс. Дополнительный элемент с именем «paths» указывает на файл + package.json, в котором определены зависимости проекта.

Определите рабочие места сбора и тестирования зависимостей

Наконец, мы определяем реальные процессы непрерывной интеграции, используя Concourse * jobs *:

Ки / pipeline.yml

. . .

jobs:
 - name: Install dependencies
   plan:
     - get: hello_hapi
       trigger: true
     - get: dependency-cache
 - name: Run tests
   plan:
     - get: hello_hapi
       trigger: true
       passed: [Install dependencies]
     - get: dependency-cache
       passed: [Install dependencies]
     - task: run the test suite
       file: hello_hapi/ci/tasks/run_tests.yml

В этом разделе мы определяем два задания, каждое из которых состоит из имени и плана. Каждый из наших планов, в свою очередь, содержит элементы «получить» и «задача». Элементы * task * определяют, как выполнить действие, в то время как элементы * get * указывают на зависимости ресурса задачи.

Первая работа не имеет никаких постановок задачи. Это немного необычно, но имеет смысл, когда мы смотрим на то, что он делает и как его можно использовать. Первый оператор get требует ресурса + hello_hapi + и указывает опцию + trigger: true +. Это говорит Concourse автоматически загружать репозиторий и начинать новую сборку этого задания каждый раз, когда в репозитории + hello_hapi + обнаруживается новый коммит.

Для второго оператора get в первом задании (+ get: dependency-cache +) требуется определенный нами ресурс, который загружает и кэширует зависимости проекта Node.js. Этот оператор оценивает требования, найденные в файле + package.json +, и загружает их. Если для этого задания не определены задачи, другие действия не выполняются, но загруженные зависимости будут доступны для последующих заданий.

Второе задание (+ name: Run tests +) начинается с объявления тех же зависимостей с одним заметным отличием. «Переданное» ограничение заставляет операторы get соответствовать только тем ресурсам, которые успешно прошли предыдущие шаги в конвейере. Так формируются зависимости между заданиями для объединения конвейерных процессов.

После операторов get определяется задача «запустить набор тестов». Вместо того, чтобы определять шаги для завершения inline, он говорит Concourse извлечь определение из файла в хранилище, которое он выбрал. Мы создадим этот файл дальше.

Когда вы закончите, весь конвейер должен выглядеть так:

Ки / pipeline.yml

---
resource_types:
 - name: npm-cache
   type: docker-image
   source:
     repository: ymedlop/npm-cache-resource
     tag: latest

resources:
 - name: hello_hapi
   type: git
   source: &repo-source
     uri: https://github.com//hello_hapi
     branch: master
 - name: dependency-cache
   type: npm-cache
   source:
     <<: *repo-source
     paths:
       - package.json

jobs:
 - name: Install dependencies
   plan:
     - get: hello_hapi
       trigger: true
     - get: dependency-cache
 - name: Run tests
   plan:
     - get: hello_hapi
       trigger: true
       passed: [Install dependencies]
     - get: dependency-cache
       passed: [Install dependencies]
     - task: run the test suite
       file: hello_hapi/ci/tasks/run_tests.yml

Сохраните и закройте файл, когда вы закончите.

Определение тестовой задачи

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

Откройте новый файл в каталоге + ci / tasks + с именем + run_tests.yml +:

nano ci/tasks/run_tests.yml

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

Вставьте следующее содержимое, чтобы настроить нашу задачу тестирования:

CI / задачи / run_tests.yml

---
platform: linux

image_resource:
 type: docker-image
 source:
   repository: node
   tag: latest

inputs:
 - name: hello_hapi
 - name: dependency-cache

run:
 path: hello_hapi/ci/scripts/run_tests.sh

В приведенной выше конфигурации мы указываем, что для этой задачи требуется работник Linux. Сам сервер Concourse может удовлетворить это требование без дополнительной настройки.

Далее мы указываем изображение, которое будет использоваться работником для запуска задачи. Хотя вы можете создавать и использовать свои собственные типы изображений, на практике это почти всегда будет изображение Docker. Поскольку наш репозиторий является приложением Node.js, мы выбираем самый последний образ «узла» для запуска наших тестов, поскольку на нем уже установлены соответствующие инструменты.

Задачи конкурса могут указывать входы и выходы, чтобы указать ресурсы, к которым он должен получить доступ, и артефакты, которые он произведет. Входные данные соответствуют ресурсам, использованным ранее на уровне «работа». Содержимое этих ресурсов доступно для среды задач в виде каталога верхнего уровня, которым можно манипулировать во время выполнения задачи. Здесь репозиторий приложения будет доступен в каталоге + hello_hapi +, а зависимости Node.js будут доступны в каталоге с именем + dependency-cache +. При выполнении шага выполнения может потребоваться переместить файлы или каталоги в их ожидаемое местоположение в начале задач и поместить артефакты в выходные места в конце задач.

Наконец, элемент * run * содержит * путь * к команде для запуска. Каждая задача может быть только одной командой с аргументами, поэтому, хотя можно создать встроенную команду, составив строку bash, более распространенным является указание задачи на файл сценария. В этом случае мы указываем на скрипт во входной директории + hello_hapi +, расположенный в + hello_hapi / ci / scripts / run_tests.sh +. Мы создадим этот скрипт дальше.

Сохраните и закройте файл, когда вы закончите.

Определение тестового скрипта

Наконец, нам нужно создать скрипт, который будет выполнять задача. Откройте новый файл с именем + run_tests.sh +, расположенный в + ci / scripts / run_tests.sh +:

nano ci/scripts/run_tests.sh

Этот сценарий будет манипулировать входными данными среды тестирования, чтобы перемещать элементы в их правильное местоположение. Затем он запустит набор тестов, определенный в репозитории, запустив + npm test.

Вставьте следующее в новый файл:

CI / скрипты / run_tests.sh

#!/usr/bin/env bash

set -e -u -x

mv dependency-cache/node_modules hello_hapi
cd hello_hapi && npm test

Во-первых, мы указываем, что этот скрипт должен выполняться интерпретатором Docker-контейнера + bash. Параметры + set + изменяют поведение оболочки по умолчанию, чтобы любые ошибки или неустановленные переменные останавливали выполнение скрипта и печатали каждую команду по мере их выполнения. Это помогает сделать сценарий более безопасным и обеспечивает большую прозрачность в целях отладки.

Первая команда, которую мы запускаем, перемещает кэшированные зависимости, расположенные в каталоге + node_modules +, из каталога + dependency-cache + в каталог + hello_hapi +. Помните, что оба эти каталога доступны, потому что мы указали их в качестве входных данных в определении задачи. В этом новом месте + npm + будет искать загруженные зависимости, которые ему требуются.

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

Когда вы закончите, сохраните и закройте файл.

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

chmod +x ci/scripts/run_tests.sh

Наш конвейер и все связанные с ним файлы теперь определены.

Настройка конвейера в конкурсе

Прежде чем мы объединяем ветку + pipeline + обратно в + main + и помещаем ее в GitHub, мы должны пойти дальше и загрузить наш конвейер в Concourse. Concourse будет отслеживать наш репозиторий на предмет новых коммитов и запускать процедуры непрерывной интеграции при обнаружении изменений.

Хотя нам нужно загрузить конвейер вручную, так как Concourse выполняет конвейер, он будет читать задачи и сценарии из каталогов в репозитории. Любые изменения в самом конвейере нужно будет перезагрузить в Concourse, чтобы они вступили в силу, но, поскольку мы не определили все встроенное, изменения в задачах или сценариях будут автоматически замечены, когда они будут загружены как часть коммита.

Чтобы настроить новый конвейер, выберите целевой сервер Concourse с помощью команды fly с помощью действия + set-pipe +. Нам нужно передать имя нового конвейера с опцией + -p + и передать файл конфигурации конвейера с опцией + -c +:

fly -t main set-pipeline -p hello_hapi -c ci/pipeline.yml

Перед продолжением вам будет предложено подтвердить конфигурацию. Введите * y * и нажмите * ENTER *:

Output. . .

apply configuration? [yN]:
pipeline created!
you can view your pipeline here: https://example.com/teams/main/pipelines/hello_hapi

the pipeline is currently paused. to unpause, either:
 - run the unpause-pipeline command
 - click play next to the pipeline in the web ui

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

В веб-браузере зайдите на сервер Concourse и войдите в систему. Вы должны увидеть ваш новый конвейер, определенный визуально:

изображение: https: //assets.digitalocean.com/articles/concourse_usage_1604/inactive_pipeline.png [Зал неактивного конвейера]

Ожидающие задания представлены серыми прямоугольниками, а ресурсы - более мелкими темными блоками. Задания, вызванные изменениями ресурса, связаны сплошными линиями, в то время как не запускающие ресурсы используют прерывистые линии. Ресурсы, проходящие out заданий, указывают, что ограничение «+ пройдено +» было установлено для следующего задания.

Синий заголовок указывает, что конвейер в данный момент приостановлен. Нажмите значок * меню (три горизонтальные линии в верхнем левом углу), чтобы открыть меню. Вы должны увидеть запись для вашего конвейера (вам может потребоваться выйти из системы и войти обратно, если конвейер не виден). Нажмите синий значок * play * рядом с конвейером, чтобы сделать паузу:

изображение: https: //assets.digitalocean.com/articles/concourse_usage_1604/unpause_pipeline.png [сборище приостановить конвейер]

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

В самом начале различные ресурсы и задания могут стать оранжевыми, указывая на возникшие ошибки. Это происходит потому, что необходимо загружать различные образы Docker, а ветку + pipe + все еще нужно объединить с веткой + main + нашего репозитория, чтобы сделать файлы задач и скриптов доступными.

Внесение изменений в Git

Теперь, когда процесс непрерывной интеграции определен, мы можем зафиксировать его в нашем репозитории + git + и добавить его в Concourse.

Добавьте новый каталог + ci + в область подготовки, набрав:

git add ci

Проверьте файлы для фиксации, проверив статус:

git status
OutputOn branch pipeline
Changes to be committed:
 (use "git reset HEAD <file>..." to unstage)

   new file:   ci/pipeline.yml
   new file:   ci/scripts/run_tests.sh
   new file:   ci/tasks/run_tests.yml

Подтвердите изменения, набрав:

git commit -m 'Add Concourse pipeline'

Изменения теперь зафиксированы в нашей ветке + pipeline +. Мы можем объединить ветвь обратно в ветку + master +, переключая ветки и объединяя:

git checkout master
git merge pipeline

Теперь переместите ветку + master + с новыми изменениями обратно в GitHub:

git push origin master

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

Просмотр новой сборки

Вернувшись в веб-интерфейс Concourse, новая сборка начнет выполняться через конвейер в течение следующей минуты:

изображение: https: //assets.digitalocean.com/articles/concourse_usage_1604/running_test.png [Конкурс, запускающий набор тестов]

Желтый контур указывает на то, что работа в данный момент выполняется. Чтобы отслеживать прогресс, нажмите на задание * Выполнить тесты *, чтобы увидеть текущий результат. Как только задание будет завершено, будет доступен полный вывод, и задание должно стать зеленым:

изображение: https: //assets.digitalocean.com/articles/concourse_usage_1604/successful_tests.png [Конкурс успешных тестов]

Нажмите на значок * home *, чтобы вернуться к экрану основного конвейера. Зеленый статус каждого задания указывает, что последний коммит прошел все стадии конвейера:

изображение: https: //assets.digitalocean.com/articles/concourse_usage_1604/passed_all_jobs.png [Конкурс прошел все задания]

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

Заключение

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

Concourse обеспечивает большую гибкость и возможность определять отдельные процедуры тестирования и хранить их в самом хранилище. Если вы хотите узнать больше о том, как использовать Concourse для ваших собственных проектов, check официальной документации.

Related