Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Локальный запуск тестов - персональная ответственность. Хорошие разработчики используют тесты непрерывно во время разработки и обязательно запускают их перед пушем (git push).

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

3 Непрерывная интеграция - практика разработки, которая заключается в частой автоматизированной сборке приложения для быстрого выявления проблем. Обычно интеграция выполняется на коммиты в репозиторий. За этим следит либо специальный сервер, либо сервис непрерывной интеграции. Он загружает код, собирает его (если это нужно для текущего приложения) и запускает различные проверки. Что и как запускать - определяется программистом. В первую очередь это тесты и линтер (проверка оформления кода). Кроме них могут запускаться утилиты, анализирующие безопасность, актуальность зависимостей и многое другое.

4 Немного терминологии и описание процесса. На каждый коммит запускается сборка (build). Во время сборки собирается приложение, устанавливаются зависимости, прогоняются тесты и все остальные проверки. Сборка, завершившаяся без ошибок, считается успешной. Если сборка не проходит, то программист получает уведомление. Дальше он смотрит отчёт и исправляет ошибки.

5 Для внедрения непрерывной интеграции есть два пути. Первый, поставить себе на сервер Jenkins или его аналог. Этот вариант требует много ручной работы (плюс поддержка сервера). Он подходит компаниям, в которых очень сложные приложения, или они не хотят допускать утечки кода наружу, или у них настолько много проектов, что свой сервер дешевле, чем стороннее решение. Второй путь - воспользоваться сервисом непрерывной интеграции. Таких сервисов десятки, если не сотни. Есть из чего выбрать. Как правило, большинство из них бесплатны для открытых проектов.

6 <h2>Github Actions</h2>

7 GitHub Actions - бесплатная система, которая позволяет автоматизировать какие-либо действия, важные для процесса разработки. Она обеспечивает непрерывную интеграцию (но может гораздо больше). Хекслет использует Actions во всех своих открытых и закрытых проектах (<a>пример</a>). С её помощью можно запускать определенный код каждый раз, когда происходит некое событие.

8 Например:

9 <ul><li>запустить проверку кода линтером и тестами</li>

10 <li>отправить код на сервер (деплой)</li>

11 <li>подключить оповещения в мессенджер о событиях в репозитории (новые issue, PR)</li>

12 <li>и многое другое</li>

13 </ul>В этом уроке мы разберёмся в основных концепциях системы, а затем рассмотрим пример настройки, чтобы быстро начать работу с Actions в своём репозитории.

14 Для удобства, GitHub Action предоставляет "бейджик" - картинку, которая вставляется в файл проектаREADME.md. Она показывает текущий статус проекта (успешно завершено последнее задание или нет), и по клику на неё можно попасть на страницу с результатами выполнения задания.

15 <h3>Основные понятия</h3>

16 Начнём с основ. На картинке ниже показаны основные концепции GitHub Actions. Разберем их по порядку.

17 <ul><li>Воркфлоу / Workflows

18 Каждый репозиторий на GitHub может содержать один или несколько воркфлоу. Каждый воркфлоу определяется в отдельном файле конфигурации в каталоге репозитория.github/workflows. Несколько воркфлоу могут выполняться параллельно.

19 </li>

20 <li>События / Events

21 Воркфлоу может запускаться одним или несколькими событиями. Это могут быть внутренние события GitHub (например, пуш, релиз или пул-реквест), запланированные события (запускаются в определенное время - например, cron), или произвольными внешними событиями (запускаются вызовом Webhook API GitHub).

22 </li>

23 <li>Задания / Jobs

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

25 </li>

26 <li>Раннеры / Runners

27 Каждое задание выполняется на определённом раннере, - временном сервере на GitHub с выбранной операционной системой (Linux, macOS или Windows). Также существуют<a>автономные раннеры</a>, которые позволяют создать своё окружение для выполнения экшена.

28 </li>

29 <li>Шаги / Steps

30 Задания состоят из последовательности шагов. Шаг - это либо команда оболочки (shell command), либо экшен (action). Все шаги задания выполняются последовательно на раннере, связанном с заданием. По умолчанию в случае сбоя шага все следующие шаги задания пропускаются.

31 </li>

32 <li>Экшен / Actions

33 Экшен - многократно используемый блок кода, который может служить шагом задания. Каждый экшен может принимать на вход параметры и создавать любые значения, которые затем можно использовать в других экшенах. Разработчики могут создавать собственные экшены или использовать опубликованные сообществом GitHub. Общих экшенов около тысячи, все они доступны на<a>GitHub Marketplace</a>.

34 </li>

35 </ul><h3>Пример воркфлоу. Hello, World!</h3>

36 Этот воркфлоу не делает ничего особенного - он просто показывает фразуHello, World!в стандартном выводе runner всякий раз, когда происходит отправка кода в репозиторий. Вот как выглядит код этого воркфлоу:

37 Разберём его в деталях:

38 <ul><li>Имя воркфлоу hello-world, определяется полем<a>name</a>.</li>

39 <li>Воркфлоу запускается событием<a>push</a>, которое определяет поле<a>on</a>.</li>

40 <li>Воркфлоу содержит одно задание с идентификатором my-job - в нём указано имя задания.</li>

41 <li>В задании my-job используется runner ubuntu-latest из GitHub Marketplace - он определяется полем<a>runs-on</a>.</li>

42 <li>Задание my-job содержит один шаг с именем my-step. На этом шаге выполняется<a>команда оболочки</a>echo- в нашем случае это"Hello World!".</li>

43 </ul>Все элементы синтаксиса для определения воркфлоу можно найти на странице<a>справки по синтаксису воркфлоу в документации</a>GitHub Actions.

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

45 Затем переходим во вкладку actions и в левой части экрана в списке рабочих процессов ищем "hello-world". Воркфлоу запускается при пуше - информация об этом показана в правой части экрана.

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

47 Если вы хотите проверить корректность запуска, откройте уведомление - на новом экране будет показаны все задания воркфлоу, а при нажатии на my-job - все детали заданий.

48 Процесс состоит из трёх шагов: set up job, my-step и complete job. Первый и последний добавляются автоматически, а my-step определяется при создании воркфлоу.

49 На каждый шаг можно кликнуть и получить дополнительную информацию о нем:

50 На этом всё - вы только что создали и запустили первый воркфлоу в GitHub Actions.

51 Не стоит останавливаться на достигнутом: этот воркфлоу можно адаптировать для вашего сценария. Например, если вы делаете проект на Хекслете, то можете сделать запуск команд изMakefileна каждый пуш в GitHub.