Организация CI/CD‑пайплайна в Termux: от тестов до релизов

Termux — популярная среда выполнения и разработки под Android, которая позволяет удобно запускать сборки и тесты прямо с устройства. Однако CI/CD — это не только «запуск команд». Это воспроизводимый процесс: предсказуемые окружения, единые шаги, артефакты, проверки качества и понятная история релизов.

Ниже — практический подход к организации CI/CD‑пайплайна для проектов, которые вы ведёте в репозитории (например, Git) и хотите выполнять с помощью Termux. Материал предназначен для легитимных сценариев разработки: сборка, тестирование, упаковка и публикация результатов.

Концепция CI/CD в рамках Termux

Термин CI/CD обычно подразумевает два слоя:

• CI (Continuous Integration) — автоматическая проверка кода при каждом изменении: сборка, линтинг, тесты, анализ качества.
• CD (Continuous Delivery / Deployment) — автоматизация подготовки релиза и доставки артефактов: сборка релизной версии, подпись (при необходимости), публикация артефактов.

В Termux вы можете реализовать «рабочие шаги» пайплайна через скрипты и единый запуск. А триггеры (на событие push/PR) обычно реализуют внешние системы CI (например, GitHub Actions, GitLab CI). Тем не менее, Termux может быть:

• локальной рабочей средой для репликации шагов CI;
• источником артефактов (сборка в Termux, затем загрузка на ваш сервер);
• частью гибридного контура (локально/внутренне), когда внешний CI вызывает скрипты, а Termux выполняет задачи сборки в доступной сети.

Рекомендуемая структура проекта

Чтобы пайплайн был поддерживаемым, заранее договоритесь о структуре:

• скрипты — папка scripts/ (например, scripts/ci, scripts/build, scripts/test, scripts/release);
• конфигурации — .env (без секретов в репозитории) и файлы конфигурации инструментов;
• артефакты — папка artifacts/ с очисткой перед сборкой;
• версии — единый файл версии (например, VERSION или поле в pyproject.toml/package.json);
• документация шагов — кратко: как запустить локальный пайплайн на Termux.

Подготовка окружения в Termux

Базовая цель — повторяемость. Типичный набор шагов:

1. Обновить пакеты и установить зависимости проекта.
2. Настроить переменные окружения.
3. Зафиксировать версии зависимостей (где возможно).
4. Убедиться, что артефакты складываются в предсказуемый каталог.

Пример подготовки (универсальный, без привязки к конкретному языку — ниже вы подставите свои команды для Python/Node/Java и т.п.):

pkg update -y
pkg upgrade -y
pkg install -y git bash curl unzip

Далее — логично создать скрипт «старт пайплайна», который будет выполнять common‑шаги:

#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

export TERMUX_PROJECT_DIR="$(pwd)"
mkdir -p artifacts

# Опционально: очистка артефактов перед сборкой
rm -rf artifacts/*
mkdir -p artifacts

Реализация CI‑шагов: сборка, проверки, тесты

CI обычно включает следующие стадии:

• lint — проверки стиля/качества;
• build — сборка;
• test — автотесты;
• package — упаковка артефакта (zip/tar/whl/js bundle и т.п.).

Пример каркаса скрипта CI (универсальный):

#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

# 1) Линт (если применимо)
if [ -f "package.json" ]; then
  # пример для Node-проектов
  npm ci
  npm run lint
fi

# 2) Сборка
if [ -f "pyproject.toml" ]; then
  # пример для Python-проектов (замените под ваш стек)
  python -m pip install -U pip
  python -m pip install -r requirements.txt
  # python -m build  # если используете build
fi

# 3) Тесты
if [ -f "pyproject.toml" ]; then
  pytest -q
fi

# 4) Упаковка артефакта
# Пример универсальной упаковки папки dist/ или build/
if [ -d "dist" ]; then
  tar -czf "artifacts/app-$(date +%Y%m%d-%H%M%S).tar.gz" dist
fi

echo "CI finished successfully"

Ключевой момент: скрипт должен завершаться с корректным кодом выхода (используйте set -euo pipefail), чтобы внешний CI мог понять успех/провал.

Релизы и CD: создание версии и публикация артефакта

CD в Термуксе можно построить как отдельный этап. Логика часто такая:

• определить номер версии;
• собрать релиз в «чистом» каталоге;
• сформировать артефакт (например, tar.gz);
• передать артефакт во внешнее хранилище/на сервер (внутреннее или публичное — на ваше усмотрение);
• сохранить метаданные релиза.

Пример релизного скрипта:

#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

VERSION="${VERSION:-0.0.0}"
OUT="artifacts/release-${VERSION}-$(date +%Y%m%d-%H%M%S).tar.gz"

# Сборка релиза (замените под ваш стек)
# npm ci && npm run build
# python -m pip install -r requirements.txt && python -m build

# Упаковка
if [ -d "dist" ]; then
  tar -czf "$OUT" dist
else
  echo "dist/ not found; place build output into dist/" >&2
  exit 1
fi

echo "Release created: $OUT"

Публикацию артефакта выполняйте легитимным способом: через ваш сервер (например, SSH/SFTP), через внутреннее хранилище, или через API сервиса, где у вас есть доступ. Для авторизации используйте переменные окружения и храните секреты вне репозитория.

Триггеры: как связать Termux с внешним CI

Если ваша цель — именно «CI/CD», то правильнее вынести триггеры в специализированную систему (GitHub Actions/GitLab CI и т.п.), а Termux использовать как среду для выполнения шагов сборки по запросу.

Практическая схема:

• Push/PR → внешний CI запускает pipeline;
• Pipeline step → выполняет ваши скрипты сборки/тестов (не обязательно на Android);
• Артефакты → сохраняются в хранилище CI.

Если вы всё же хотите, чтобы команда сборки выполнялась именно в Termux (например, для специфичных задач или локальной разработки), создайте способ удалённого запуска скриптов в вашей локальной сети (например, на своём сервере/мини‑CI). Важно: используйте VPN строго для создания локальной сети, а не для обхода блокировок.

Технически это выглядит как:

• вы поднимаете локальную сеть между устройствами;
• в CI запускается шаг, который по сети вызывает скрипт на вашем устройстве (направленный запрос в рамках вашей инфраструктуры);
• результаты возвращаются и сохраняются как артефакты.

Артефакты и история сборок

Чтобы CI/CD был полезным, артефакты должны:

• иметь уникальные имена (версия + timestamp или commit hash);
• храниться в каталоге artifacts/;
• быть воспроизводимыми (одно и то же входное состояние → предсказуемый результат).

Рекомендуемый стандарт имени:

release-${VERSION}-${GIT_COMMIT_HASH}.tar.gz

Качество: кэширование, логи и воспроизводимость

Для стабильности пайплайна:

• минимизируйте «скачки» окружения: используйте фиксированные версии зависимостей;
• обязательно логируйте ключевые шаги: версии инструментов, параметры сборки;
• делайте очистку перед сборкой (rm -rf целевых build‑каталогов);
• если применимо — используйте кэш зависимостей (локально или на стороне внешнего CI).

Безопасность и секреты

Секреты (токены, пароли) не храните в репозитории. В Termux передавайте секреты через переменные окружения, например:

export RELEASE_API_TOKEN="your_token_here"

Далее в скриптах обращайтесь к $RELEASE_API_TOKEN. Для логов следите, чтобы токены не выводились на экран (не делайте echo $TOKEN).

Проверка пайплайна «на своей машине»

Перед тем как полагаться на CI/CD, выполните локальный прогон скриптов в Termux:

bash scripts/ci/run-ci.sh
bash scripts/release/run-release.sh

Если скрипты корректно проходят локально, вероятность успеха в внешнем пайплайне выше.

Заключение

CI/CD‑подход в Termux сводится к созданию воспроизводимых скриптов (CI‑проверки и релизные сборки), управлению артефактами и корректной интеграции с внешними триггерами. Termux становится удобной средой для реального запуска шагов сборки и тестов, а внешняя CI‑система — источником событий и хранителем истории.

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