Gitea Actions: установка и настройка встроенного CI/CD для автоматизации задач в вашем репозитории

В этой статье мы рассмотрим Gitea Actions – встроенный в Gitea инструмент автоматизации CI/CD, совместимый с GitHub Actions.

Как и другие CI/CD-решения, Gitea не выполняет задания самостоятельно, а делегирует их исполнителям – раннерам. На время выполнения задания раннер создает Docker-контейнер, в котором выполняются все этапы рабочего процесса.

В данной статье мы будем использовать VPS/VDS с развернутой Gitea – данное готовое решение доступно в маркетплейсе Beget.

Установка Gitea Actions

Начиная с версии Gitea 1.21.0, Actions включены по умолчанию. Если вы используете более старую версию, активируйте Actions согласно официальной документации или выполните обновление. Если вы установили Gitea из маркетплейса Beget, инструкция доступна в блоке FAQ на странице готового решения.

Создание раннера

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

Сперва загрузите версию раннера для вашей операционной системы и архитектуры со страницы загрузки (убедитесь, что загружаете последнюю версию для вашей операционной системы и архитектуры – в нашем примере используется версия 0.2.13 для Linux amd64):

wget https://dl.gitea.com/act_runner/0.2.13/act_runner-0.2.13-linux-amd64

Дайте файлу разрешение на исполнение:

chmod +x act_runner-0.2.13-linux-amd64

Для удобства переименуем его в act_runner и переместим в директорию с пользовательскими бинарными файлами:

$ mv act_runner-0.2.13-linux-amd64 act_runner 
$ sudo mv act_runner /usr/local/bin/

Поскольку при работе раннер будет создавать Docker-контейнер, необходимо добавить пользователя, из-под которого будет запускаться раннер, в группу Docker:

sudo usermod -aG docker user

Проверим:

$ act_runner -v 
act_runner version v0.2.13

Раннер готов к запуску. Вы можете как запускать его вручную, через командную строку, так и настроить автозапуск с помощью systemd. Рассмотрим оба варианта.

Запуск в терминале

Обратите внимание!
Для корректной работы раннера Docker должен быть установлен и запускаться при старте системы.

Перед началом работы раннер необходимо зарегистрировать в Gitea:

act_runner register --no-interactive --instance <instance> --token <token>

Вместо <instance> укажите путь к виртуальному серверу с запущенной Gitea, например: https://betutorial.beget.app.

Для получения токена в панели Gitea перейдите в: Настройки (Settings) > Действия (Actions) > Раннеры (Runners), нажмите на кнопку “Создать новый раннер” и скопируйте Registration token:

панель gitea

В случае успешной регистрации вы увидите сообщение:

INFO Runner registered successfully.

А раннер появится в списке:

runners management gitea

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

act_runner daemon

Если вы хотите, чтобы раннер продолжал работу при закрытии терминала, вы можете запустить его, например, с помощью утилиты tmux. Однако чтобы раннер автоматически запускался при старте системы, мы рекомендуем настроить запуск с помощью systemd-юнита.

Настройка запуска через systemd

Обратите внимание!
Для корректной работы раннера Docker должен быть установлен и запускаться при старте системы.

В целях безопасности мы рекомендуем создать отдельного пользователя, из-под которого будет запускаться раннер, и добавить его в группу Docker:

$ sudo useradd -m gitea_runner 
$ sudo usermod -aG docker gitea_runner

Далее создайте директорию для раннера и директорию, в которой будет храниться конфигурационный файл:

$ sudo mkdir /var/lib/act_runner /etc/act_runner 
$ sudo chown -R root:gitea_runner /etc/act_runner /var/lib/act_runner

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

act_runner register --no-interactive --instance <instance> --token <token>

После чего сформируем конфигурационный файл раннера:

act_runner generate-config > config.yaml

Меняем владельца и перемещаем файлы: .runner в рабочую директорию раннера, config.yaml – в директорию с конфигурационными файлами.

$ sudo chown gitea_runner:gitea_runner .runner config.yaml 
$ sudo mv config.yaml /etc/act_runner $ sudo mv .runner /var/lib/act_runner

Остается только создать файл системного юнита /etc/systemd/system/act_runner.service со следующим содержимым:

[Unit] 
Description=Gitea Actions runner
Documentation=https://gitea.com/gitea/act_runner 
After=docker.service

[Service] 
ExecStart=/usr/local/bin/act_runner daemon --config /etc/act_runner/config.yaml 
ExecReload=/bin/kill -s HUP $MAINPID 
WorkingDirectory=/var/lib/act_runner 
TimeoutSec=0 
RestartSec=10 
Restart=always 
User=gitea_runner

[Install] 
WantedBy=multi-user.target

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

sudo systemctl daemon-reload 
sudo systemctl enable --now act_runner.service

Проверим, что служба запустилась:

systemctl status act_runner.service 
● act_runner.service - Gitea Actions runner 
	Loaded: loaded (/etc/systemd/system/act_runner.service; disabled; vendor preset: enabled) 
	Active: active (running)

Если служба не запустилась, проверьте системный журнал на предмет ошибок с помощью команды journalctl -xeu 'act_runner'.

Запуск тестового рабочего процесса

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

Сперва создайте директорию в корне вашего git-репозитория, в которой будут храниться файлы рабочих процессов:

mkdir -p .gitea/workflows

Создайте файл рабочего процесса в формате .yaml:

vim .gitea/workflows/demo.yaml

Добавьте в файл следующее содержимое:

on: [push] 
jobs: 
	print-content: 
		runs-on: ubuntu-latest 
		steps: 
		- name: checkout code 
			uses: actions/checkout@v4 
		- name: list directory contents 
			run: ls -la

Рассмотрим рабочий процесс построчно:

  • on – ключ, который определяет триггер для запуска рабочего процесса. В данном случае процесс запустится при выполнении push в репозитории;
  • job – содержит список задач, выполняемых в рамках рабочего процесса. Один процесс может содержать несколько задач;
  • print-content – наименование задачи;
  • runs-on – содержит наименование лейбла. Рабочий процесс будет запускаться только на раннерах, содержащих лейбл, указанный в этой строке, в нашем случае это ubuntu-latest;
  • steps – каждая задача включает в себя один или несколько этапов. Первый этап – checkout code, использует готовый action из маркетплейса GitHub Actions, чтобы рабочий процесс мог получить доступ к репозиторию. Для запуска готовых actions используется ключ uses;
  • name: list directory contents – в этом этапе выводится список всех файлов и директорий репозитория. Для выполнения команды ls -la используется ключ run.

Gitea читает файлы рабочих процессов из репозитория, поэтому чтобы action запустился, необходимо выполнить commit и push файла вашего процесса как при создании, так и при его изменении.

Так как условие запуска рабочего процесса – push, он сразу начнет выполняться и появится в разделе “Actions” в вашем репозитории.

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

actions gitea

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

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

Cоздадим файл рабочего процесса deploy.yaml со следующим содержимым:

on: push 
name: publish site 
jobs: 
	deploy: 
		name: deploy site 
		runs-on: ubuntu-latest 
		steps:  
		- name: checkout code 
		uses: actions/checkout@v4

		- name: create ssh key
		run: mkdir -p /root/.ssh; echo "${{ secrets.SSH_KEY }}" > /root/.ssh/id_rsa; chmod 600 /root/.ssh/id_rsa

		- name: sync files
		run: scp -r -o StrictHostKeyChecking=no  $(pwd)/* betutorial_new@betutorial.beget.tech:~/betutorial.ru/public_html/

Данный процесс также запускается при push и состоит из трех этапов:

  1. Как и в тестовом процессе, делаем checkout с помощью одноименного action, чтобы файлы репозитория были доступны в контейнере, создаваемом раннером.
  2. Создаем приватный SSH-ключ внутри контейнера, выставляем на файл корректные права.
  3. Копируем файлы репозитория в удаленную директорию с помощью scp.

В данном примере SSH-ключ был получен из Secrets – специального пространства в Gitea, где вы можете хранить чувствительные данные, используемые в пайплайнах.

Создание Secrets

Для добавления значения в Secrets перейдите в: Настройки (Settings) > Действия (Actions) > Секреты (Secrets) и нажмите на кнопку “Добавить секрет”.

secrets gitea

Как видно из рабочего процесса, конструкция для использования секрета следующая: ${{ secrets.SSH_KEY }}, где название секрета – SSH_KEY.

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

управление переменными gitea

Для добавления переменных в рабочий процесс используется конструкция ${{ vars.VARIABLE_NAME }}.

Запуск рабочего процесса

Теперь, когда всё готово, выполним push:

панель gitea запуск заданий

Все этапы завершились без ошибок, файлы сайта успешно загружены в удаленную директорию.

На этом всё, настройки Gitea завершены. Если возникнут вопросы, напишите нам, пожалуйста, тикет из панели управления аккаунта (раздел “Помощь и поддержка”), а если вы захотите обсудить эту статью или наши продукты с коллегами по цеху и сотрудниками облачной ИТ-платформы Beget – ждем вас в нашем сообществе в Telegram.

1
869