В этой статье мы рассмотрим 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. Рассмотрим оба варианта.
Запуск в терминале
Перед началом работы раннер необходимо зарегистрировать в Gitea:
act_runner register --no-interactive --instance <instance> --token <token>Вместо <instance> укажите путь к виртуальному серверу с запущенной Gitea, например: https://betutorial.beget.app.
Для получения токена в панели Gitea перейдите в: Настройки (Settings) > Действия (Actions) > Раннеры (Runners), нажмите на кнопку “Создать новый раннер” и скопируйте Registration token:

В случае успешной регистрации вы увидите сообщение:
INFO Runner registered successfully.А раннер появится в списке:

Для запуска раннера выполните команду:
act_runner daemonЕсли вы хотите, чтобы раннер продолжал работу при закрытии терминала, вы можете запустить его, например, с помощью утилиты tmux. Однако чтобы раннер автоматически запускался при старте системы, мы рекомендуем настроить запуск с помощью systemd-юнита.
Настройка запуска через systemd
В целях безопасности мы рекомендуем создать отдельного пользователя, из-под которого будет запускаться раннер, и добавить его в группу 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” в вашем репозитории.
Согласно условиям, в выводе будет отображен список файлов и каталогов:

Запуск рабочего процесса для автоматического развертывания сайта
Чтобы посмотреть, как работают 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 и состоит из трех этапов:
- Как и в тестовом процессе, делаем checkout с помощью одноименного action, чтобы файлы репозитория были доступны в контейнере, создаваемом раннером.
- Создаем приватный SSH-ключ внутри контейнера, выставляем на файл корректные права.
- Копируем файлы репозитория в удаленную директорию с помощью scp.
В данном примере SSH-ключ был получен из Secrets – специального пространства в Gitea, где вы можете хранить чувствительные данные, используемые в пайплайнах.
Создание Secrets
Для добавления значения в Secrets перейдите в: Настройки (Settings) > Действия (Actions) > Секреты (Secrets) и нажмите на кнопку “Добавить секрет”.

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

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

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