Termux + GitLab CI/CD: настройка пайплайнов для сборки, тестирования и деплоя приложений прямо из терминала смартфона

Меня зовут Усачёв Денис Евгеньевич, ведущий эксперт РыбинскЛАБ. В этой статье покажу, как связать Termux с GitLab CI/CD, чтобы вы могли готовить проект, запускать сборку/тесты локально на смартфоне и при этом полноценно запускать пайплайны на стороне GitLab. Такой подход особенно удобен, когда нужно быстро проверить изменения, подготовить артефакты и передать их в CI без сложных ручных процессов.

Зачем соединять Termux и GitLab CI/CD

Termux — это полноценное терминальное окружение на Android. GitLab CI/CD — автоматизация жизненного цикла приложения на CI-раннере. Комбинация даёт сразу несколько преимуществ:

Быстрая проверка кода на смартфоне (lint, unit-тесты, генерация артефактов).
Единый сценарий CI в .gitlab-ci.yml — сборка, тестирование, публикация.
Согласованность: окружение для сборки и команды повторяемы в CI.
Удобная доставка артефактов: можно собирать и отправлять контейнеры/бандлы/пакеты на нужные этапы.

Важно: CI/CD в GitLab выполняется на раннере. Termux помогает готовить проект, управлять репозиторием, конфигами и (при необходимости) подготавливать артефакты/задания, которые затем забирает пайплайн.

Предварительные условия

Android-смартфон с установленным Termux.
Доступ к GitLab (с проектом и правами на настройки CI).
Репозиторий с проектом, для которого будем собирать и тестировать.
Понимание, какой тип деплоя вам нужен: публикация релиза, загрузка артефакта, обновление сервиса, деплой в тестовую среду.

Подготовка Termux: инструменты и окружение

Начнём с базовой подготовки: обновим пакеты, поставим Git, утилиты сборки и клиент командной строки GitLab (опционально).

pkg update -y
pkg upgrade -y
pkg install -y git curl openssh tar unzip nano

Для большинства языков (например, Node.js/Java/Python/Go) нужны дополнительные пакеты. Ниже приведём пример для Node.js и покажем, как адаптировать под вашу технологию.

pkg install -y nodejs-lts npm

Проверьте версии:

node -v
npm -v
git --version
curl --version

Клонирование репозитория в Termux и первичная проверка

Клонируйте репозиторий:

git clone <URL_вашего_репозитория>
cd <имя_репозитория>

Установите зависимости и запустите тесты локально (пример для Node.js):

npm ci
npm test

Если у вас другое окружение, команды будут иными, но логика та же: на Termux вы быстро валидируете изменения перед отправкой в репозиторий.

Организация репозитория для CI

Для GitLab CI/CD важно, чтобы ваш проект имел понятную структуру сценариев. Обычно в репозитории используется файл .gitlab-ci.yml. Размещайте его в корне проекта.

Рекомендованная практика:

Разделить стадии на build, test, deploy.
Использовать артефакты сборки.
Хранить секреты (токены, ключи) в GitLab CI/CD Variables, а не в репозитории.

Базовый пример .gitlab-ci.yml для Node.js

Ниже пример пайплайна, который:

устанавливает зависимости
собирает проект
запускает тесты
публикует артефакты
на этапе deploy — выполняет скрипт деплоя (пример заглушки)

stages:
  - build
  - test
  - deploy

variables:
  NODE_ENV: 'production'

cache:
  paths:
    - node_modules/

build:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week
  only:
    - branches

test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm test
  dependencies:
    - build
  only:
    - branches

depploy:
  stage: deploy
  image: node:20
  script:
    - echo "Deploy step placeholder"
    - ls -la dist || true
    - ./scripts/deploy.sh
  dependencies:
    - build
  only:
    - main

Что важно:

image задаёт окружение на раннере GitLab.
artifacts передают результат сборки между стадиями.
only (можно заменить на rules) ограничивает запуск по веткам.

Управление конфигурациями и секретами безопасно

GitLab CI предоставляет механизм Variables. Не кладите токены и ключи в код и не коммитьте их в репозиторий.

Зайдите в Settings → CI/CD → Variables и добавьте, например:

DEPLOY_TOKEN — токен для публикации
SSH_PRIVATE_KEY — приватный ключ (если деплой по SSH)
DEPLOY_HOST, DEPLOY_USER

После этого в .gitlab-ci.yml можно использовать переменные, например:

script:
  - echo "Deploying..."
  - if [ -z "$DEPLOY_TOKEN" ]; then echo "Missing DEPLOY_TOKEN"; exit 1; fi
  - ./scripts/deploy.sh

Пример деплоя через скрипт (deploy.sh)

Сценарий деплоя лучше держать в репозитории как shell-скрипт. Логику деплоя подставляете под ваш стек.

Пример структуры:

scripts/deploy.sh
использует переменные окружения из GitLab CI

#!/usr/bin/env sh
set -eu

echo "Starting deploy..."

# Пример: публикация артефактов через токен.
# Реальную схему замените под ваш сервер/стенд.

if [ ! -d "dist" ]; then
  echo "dist folder not found"
  exit 1
fi

echo "Packaging dist..."
tar -czf dist.tar.gz dist

# Здесь могли бы быть вызовы API вашего сервиса:
# curl -X POST https://example.com/api/deploy \
#   -H "Authorization: Bearer $DEPLOY_TOKEN" \
#   -F "artifact=@dist.tar.gz"

echo "Deploy artifact prepared: dist.tar.gz"
echo "Deploy finished (placeholder)"

Не забудьте дать права на выполнение:

chmod +x scripts/deploy.sh

Как подготовить пайплайн, если вы меняете код с Termux

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

В Termux вносите изменения в проект.
Запускаете локальные проверки: npm test, npm run build (или аналоги для вашего языка).
Коммитите изменения и пушите в GitLab.
GitLab CI запускает пайплайн по правилам в .gitlab-ci.yml.

Пример команд:

git status
git add .
git commit -m "feat(ci): improve build pipeline"
git push

Запуск пайплайна вручную и просмотр результатов

После пуша откройте в GitLab страницу CI/CD → Pipelines и проверьте:

что стадия build прошла успешно
что test не падают
что deploy отрабатывает только для нужных веток (например, main)

Если нужно запускать вручную, используйте (по желанию) кнопки в интерфейсе либо настраивайте rules с условиями. Например, деплой можно делать только при наличии тега.

Локальная сеть на время отладки (опционально)

Если вы хотите быстро протестировать деплой на тестовый узел в локальной инфраструктуре, можно организовать локальную сеть с VPN исключительно для доступа внутри вашей сети (например, для взаимодействия “раннер ↔ тестовый сервер”). Это не про обход блокировок, а про удобство отладки в рамках вашей инфраструктуры.

В таком случае деплой-скрипт должен обращаться к IP/хосту из локальной сети, а переменные (host/user) храниться в GitLab Variables.

Типовые ошибки и как их избежать

Смешение окружений: если вы собираете локально в Termux, а в CI используете другой runtime-версию, возможны расхождения. Старайтесь синхронизировать версии (например, Node 20).
“Секреты в репозитории”: токены и ключи не должны попадать в git. Используйте Variables.
Отсутствие артефактов: убедитесь, что в artifacts.paths указана та же директория, которую читает следующая стадия.
Проблемы с кешем: кеш может ускорять сборку, но иногда ломается после изменения зависимостей. Если тесты/сборка начинают “вести себя странно”, отключайте кеш временно.

Расширение пайплайна: статанализ, линтеры, релизы

Когда базовый пайплайн работает, добавьте улучшения:

lint отдельной стадией
code quality отчёты (если поддерживается вашим стеком)
релиз/пакетирование на тегах

Например, добавление линтера рядом с тестами:

lint:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm run lint

Заключение

Termux и GitLab CI/CD вместе дают мощный и практичный workflow: вы можете быстро подготовить и проверить изменения на смартфоне, а затем доверить сборку, тестирование и деплой CI-раннеру в GitLab. Главное — корректно настроить .gitlab-ci.yml, передавать артефакты между стадиями, а секреты хранить в GitLab Variables.

Если хотите, чтобы мы вместе с вашей командой спроектировали пайплайн “под ключ” (под ваш стек, окружения, артефакты и схему деплоя) — обращайтесь в РыбинскЛАБ. Поможем с настройкой CI/CD, безопасностью и сопровождением.