Оглавление.

• Часть 1. Введение

• Часть 2. Запускаем CI

Список необходимых инструментов

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

И на этом сервере, мы можем выполнять любой набор команд для автоматизации.🫡

Но самый важный момент на этом этапе – какие настройки должны быть на этом сервере? Какие программы, пакеты или библиотеки, должны быть установлены? В конце концов, какую операционную систему использовать? ⚠️

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

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

eslint . –fix

npm run build

Если попробовать перечислить, то получится следующий список

• Операционная система (желательно Unix подобная)

• NodeJS (среда выполнения JS кода, которая требуется для установки и запуска наших скриптов)

• npm – пакетный менеджер, для установки и запуска скриптов.

• React – фреймворк, на котором мы ведем разработку. В нашем случае – нам нужен по идее, подготовленный для нас скрипт npm run build, который осуществляет сборку приложения.

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

Git в контейнере

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

Это верно. Если нам в процессе нашей автоматизации, понадобятся команды Git, его следует установить. Но есть нюанс. Контейнер при активации, автоматически склонирует вашу текущую ветку (для которой будет работать pipeline) и все файлы из нее. И текущей рабочей директорией назначит папку с репозиторием. Это нужно иметь ввиду – эту часть GitLab runner берет на себя, и здесь установка Git не потребуется.

Производим установку

Что помогло мне на этом этапе? Рекомендую локально установить докер, и поднять в нем контейнер с операционной системой, которую вы планируете использовать в раннере. Установите туда Git, склонируйте ваш репозиторий, и перейдите в терминале в корневую папку проекте. Все! Это исходная точка, с которой вы стартуете в контейнере раннера. Все команды, которые вы хотите автоматизировать – пробуйте выполнять здесь. Возникла ошибка? Разбираемся, где мы напутали в настройках, или чего нам не хватает. Очень удобный подход.🆗

Давайте пойдем по списку выше.

NodeJS. Выбор образа операционной системы, мы делали, на этапе настройки job-ы.

Ubuntu была выбрана как удобное и главное, подходящее решение под наши задачи. Но об этом чуть ниже.

Node JS и NPM. Эти две программы нам уже понадобится установить вручную. Потому что в базовой поставке Ubuntu, их нет среди предустановленных пакетов. Это, кстати, тот нюанс, про который упомянул ранее. Помните, что такое образом для контейнера? Это операционная система, плюс список установленных программ (слоев). Если кто-то раньше использовал разные образы для установки Windows, то вам знакомы варианты – чистые образом, где есть только операционная система. И кастомные – где сразу идет большой список предустановленных программ.

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

Image: node:23-alpine3.20

Здесь будет как сама операционка, так и сразу NodeJS+npm. И таких готовых образов большое количество. Когда мы понимаем, что и для чего нам нужно, процесс можно упростить, выбрав подходящий вариант.

Но вернемся к нашему процессу. В Ubuntu, используется менеджер пакетов apt. Это аналог Windows Installer – инструмент для установки и обновления программ. С его помощью давайте установим NodeJS. Листинг команд взят из официальной документации. Здесь нужно получить последнюю версию списка пакетов для операционной системы. Установить curl – http клиент. Указать для него адрес, по которому можно скачать Node, и выполнить установку.

Мы поместим эту часть кода в раздел before_script. Которая по своему названию, содержит предварительные команды. Хотя, насколько я успел понять – это лишь семантическое различие. Все можно запускать и в разделе script.

В комплекте установки сразу идет npm менеджер. Этими командами мы закрыли два необходимых инструмента

React. Основной фреймворк приложения. Он был установлен с помощью пакетного менеджера Vite. На выходе мы получаем базовую структуру, и готовые скрипты в package.json файле, которые можно запускать. Нам интересует скрипт сборки – чтобы наше приложение успешно билдилось, без ошибок. Запускать его будет как раз через npm.

Здесь нужно помнить – что в случае с проектами JS, обычно весь код сторонних зависимостей, не хранят в репозитории. Вместо этого в файле package.json, лежит список самих зависимостей и их версий. Для того, чтобы начать пользоваться приложением, или как в нашем случае – запускать скрипты – нам нужно эти зависимости установить. Для этого используется команда npm install. Ее нам нужно выполнить.

Добавить новую команду в раздел script

Если подвести промежуточный итог – у нас должны быть установлены, настроены и подготовлены все необходимые инструменты для наших дальнейших шагов. Здесь уже зависит от того, какой проект и на каких технологиях мы разрабатываем. От этого будет напрямую зависеть процесс подготовки.

❗️ Еще раз здесь отмечу – удобно в контейнере на локальной машине – проходить все требуемые этапы по шагам. И их переносить (в виде команд) в наш .gitlab-ci.yml файл.

Запуск основных шагов

Теперь наш сервер настроен и готов для запуска наших основных этапов – линтинга и сборки. Мы можем запускать сами скрипты, используя полную версию команды. Либо можно сохранить их в разделе scripts, в package.json файле. Это вариант создания короткого имени, для длинной команды со скриптом. Чтобы постоянно не набирать ее вручную, а запускать через короткое имя. Скрипт для сборки – добавляется автоматически при создании проекта на Vite.

Давайте выберем вариант запуска именно через package.json файл. Добавим сюда скрипт для запуска линтинга.

В общем-то, мы могли бы запускать команды напрямую – tsc -b && vite build, exlint . –fix. Но вариант через package.json будет удобно для использования в самом проекте. Поэтому за основу был взят он.

Нам осталось только добавить 2 команды в наш yaml файл.

npm run – это запуск подготовленного в package.json скрипта по имени. Сохраняем изменения, и смотрим результат выполнение job.

Никогда не думал, что скажу это – но наш процесс сборки упал очень кстати 😮. Мы видим соответствующее уведомление на страницы вывода результатов. Где-то в коде приложения, мы допустили ошибку в имени до файла, при попытке импорта из него. По сути – банальная опечатка. Но если бы не проверки – этот код мог бы улететь на дев стенд, и уронить его. А что еще хуже – уронить продуктовую сборку.

Здесь благодаря автоматизации, мы на ранней стадии смогли эту ошибку локализовать. Если бы были добавлены дополнительные шаги – деплой на сервер, то до него бы дело не дошло. Pipeline остановился бы на этой ошибке. Очень удобно.

Вносим необходимые правки, коммитим изменения. Job автоматически запускается, и через пару секунд, мы видим успешное ее завершение. Наши проверки пройдены!

Итого

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

В следующий раз, попробуем настроить процесс CD – деплоить наше приложение на дев сервер. Удачи! 😇

PS. А вам удалось запустить свой первый Pipeline? С какими трудностями вы сталкивались, при первичной настройкой CI? Чего Вам не хватило в этом руководстве? Поделитесь в комментариях!