CI/CD‑конвейеры помогают автоматизировать сборку, тестирование, упаковку и развёртывание приложений. Обычно эти задачи строят вокруг серверов (GitLab CI, GitHub Actions, Jenkins). Однако в реальных проектах часто возникает потребность быстро стартовать на локальной инфраструктуре, отладить пайплайн под конкретную среду или поддерживать сборки на мобильных устройствах. Termux предоставляет полноценную рабочую оболочку на Android и позволяет собирать и запускать скрипты так же, как в традиционной Linux‑среде.
В этой статье мы рассмотрим, как построить CI/CD‑конвейеры на базе Termux: от подготовки среды до схемы запуска задач и хранения артефактов, а также разберём практические примеры скриптов и шаблонов пайплайнов.
Что считать CI/CD в контексте Termux
CI (Continuous Integration) в нашем случае — это автоматический процесс при каждом изменении кода: установка зависимостей, сборка, запуск тестов, статический анализ (опционально) и формирование артефактов.
CD (Continuous Delivery/Deployment) — это дальнейшие шаги: упаковка релизов, публикация артефактов в репозиторий/хранилище, развёртывание в тестовую или пользовательскую среду.
Termux будет выступать как исполняющая среда: на устройстве Android выполняются скрипты сборки и тестирования. Само orchestration можно организовать двумя способами:
- Локально по расписанию/вручную (для отладки и быстрых итераций).
- По триггерам из Git‑системы через webhooks, если у вас есть сервер, который маршрутизирует события на Termux (или запускает задачи на устройстве).
Ниже мы покажем практическую схему, которая чаще всего удобна: Termux как «агент» выполнения, а централизованный планировщик — как часть вашей инфраструктуры.
Архитектура решения
Рассмотрим типовой стек компонентов:
- Репозиторий (Git): содержит код приложения и скрипты сборки/тестов.
- Termux‑агент: устройство Android с Termux, где выполняются команды.
- Секреты и переменные: токены, ключи, настройки — храните безопасно (через переменные окружения, файлы конфигурации вне репозитория).
- Хранилище артефактов: файловый ресурс, объектное хранилище или сервер, куда выгружаются сборки.
- Уведомления: отправка статуса в чат/Slack/Telegram через ваш сервер или прямые запросы, если это оправдано.
Если требуется доступ к приватным ресурсам, допускается использование VPN только для создания локальной сети между устройствами и/или сервером (без целей обхода блокировок).
Подготовка Termux: минимальный набор
Начните с базовой установки и приведения окружения к предсказуемому состоянию. В большинстве случаев удобно использовать официальный пакетный менеджер Termux и зафиксировать зависимости в ваших скриптах.
pkg update && pkg upgrade -ypkg install -y git proot-distro curl wget openssh rsyncЕсли вы собираете проекты на языке программирования, дополните набор инструментов. Например, для Node.js потребуются дополнительные пакеты/установщики, а для Python — соответствующие зависимости и виртуальные окружения.
Рекомендуется вести работу в каталоге проектов и завести отдельного пользователя/структуру (хотя бы на уровне директорий) для чистоты среды.
Размещение агента: рабочий каталог и права
Выберите фиксированный путь для работы (например, /data/data/com.termux/files/home/projects). При необходимости настройте хранение конфигов вне репозитория.
mkdir -p ~/projectscd ~/projectsКритически важно обеспечить повторяемость: сборка в разные дни не должна зависеть от случайных ручных действий. Поэтому все шаги сборки лучше описывать в скриптах репозитория.
Скрипты сборки и тестов как основа пайплайна
CI‑логика должна быть «в коде»: создайте в репозитории единый entrypoint, который умеет выполнять стадии. Терминальная среда Termux — отличная площадка для такого подхода.
Пример структуры:
- scripts/ci/run.sh — входной скрипт CI.
- scripts/ci/test.sh — тесты.
- scripts/ci/build.sh — сборка.
- scripts/ci/package.sh — упаковка артефактов.
Упрощённый entrypoint может выглядеть так:
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
STAGE="${1:-all}"
echo "CI stage: $STAGE"
case "$STAGE" in
all)
./scripts/ci/build.sh
./scripts/ci/test.sh
./scripts/ci/package.sh
;;
build)
./scripts/ci/build.sh
;;
test)
./scripts/ci/test.sh
;;
package)
./scripts/ci/package.sh
;;
*)
echo "Unknown stage: $STAGE"
exit 2
;;
esacЗадача агента Termux — просто вызывать этот скрипт и сохранять результаты.
Скачивание репозитория и подготовка рабочей копии
В CI на устройстве важно делать checkout предсказуемо. Если у вас есть агент‑планировщик, он будет передавать ссылку/ветку коммита. В простом варианте — обновляйте рабочую копию и делайте checkout нужного коммита.
REPO_URL="https://example.com/your/repo.git"
BRANCH="main"
git clone "$REPO_URL" repo || true
cd repo
git fetch --all --prune
git checkout "$BRANCH"
git pull --ff-onlyДля «настоящего» CI предпочтительнее чекать конкретный SHA, а не ветку. Это делает поведение стабильным при одновременных коммитах.
Управление зависимостями для повторяемости
Чтобы сборки не ломались из‑за изменения зависимостей, фиксируйте версии. Практики зависят от языка:
- Для Python — используйте
requirements.txtи отдельное виртуальное окружение. - Для Node.js — фиксируйте зависимости через
package-lock.jsonи запускайте установку в clean‑режиме. - Для Go — опирайтесь на
go.modи включайте модульную загрузку.
Пример с Python (универсальный паттерн):
python -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install -r requirements.txtВ CI/CD также полезно кешировать зависимости на устройстве (например, сохраняя ~/.cache), но кеширование должно быть аккуратным, чтобы не подмешивать устаревшие версии.
Сборка, тестирование и генерация артефактов
Стадии лучше разделять по ответственности:
- Build: компиляция/сборка дистрибутива.
- Test: прогон тестов, сбор отчётов (JUnit/coverage).
- Package: архивация артефактов в понятный формат (zip/tar) и запись метаданных.
Пример упаковки артефакта:
mkdir -p artifacts
VERSION="$(date +%Y%m%d)-$(git rev-parse --short HEAD)"
tar -czf "artifacts/app-$VERSION.tgz" -C build .Если вы генерируете отчёты, сохраняйте их вместе с артефактами и публикуйте как отдельные файлы.
Публикация артефактов и интеграция с хранилищем
Для CD важна доставка результатов туда, где ими может воспользоваться команда. Практичные варианты:
- Загрузка в файловый сервер через
rsyncилиscp. - Публикация в S3‑совместимое хранилище (при наличии).
- Публикация в артефакт‑репозиторий (если у вас есть корпоративная инфраструктура).
Пример отправки артефактов на сервер по SSH:
ARTIFACT_DIR="artifacts"
REMOTE_USER="buildbot"
REMOTE_HOST="192.168.1.10"
REMOTE_PATH="/srv/ci-artifacts/your-project"
ssh "$REMOTE_USER@$REMOTE_HOST" "mkdir -p '$REMOTE_PATH'"
rsync -av --delete "$ARTIFACT_DIR/" "$REMOTE_USER@$REMOTE_HOST:$REMOTE_PATH/"Такая схема хорошо работает, если у вашего Termux‑агента есть сетевой доступ к серверу (например, через локальную сеть и/или VPN для создания локальной сети).
Оркестрация: как запускать Termux‑пайплайны
Есть три распространённых подхода:
- Ручной запуск через Termux командами: подходит для экспериментов и первичной отладки.
- Запуск по расписанию (например, через cron‑подобные решения). В Termux это можно организовать через планировщики, но требования зависят от вашей конфигурации Android.
- Триггеры от Git‑событий: обычно нужен сервер, который принимает webhook и затем инициирует запуск на устройстве (или через SSH на сервере/агенте). Сам Termux‑агент при этом не обязан быть доступен извне интернет.
Практически удобно, чтобы центральная инфраструктура вызывала на вашей стороне скрипт агента по SSH или через доступный сетевой канал в локальной сети.
Пример сценария: один «агентный» скрипт
Сделайте один script на устройстве, который принимает входные параметры: репозиторий, ветка/SHA, и «секцию» пайплайна. Ниже схематичный пример.
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
REPO_URL="${REPO_URL:?need REPO_URL}"
REF="${REF:?need REF}"
WORKDIR="${WORKDIR:-$HOME/projects/agent}"
STAGE="${STAGE:-all}"
mkdir -p "$WORKDIR"
cd "$WORKDIR"
if [ ! -d repo ]; then
git clone "$REPO_URL" repo
fi
cd repo
git fetch --all --prune
git checkout -f "$REF"
chmod +x ./scripts/ci/run.sh
./scripts/ci/run.sh "$STAGE"
echo "CI finished for $REF"Дальше вы запускаете этот скрипт от вашего контроллера (локально или удалённо по SSH).
Уведомления о статусе сборки
Чтобы команда получала быстрые сигналы о результате, добавьте отправку сообщений после завершения стадий. Важно: в корпоративной среде лучше, чтобы отправка шла через ваш сервер (там проще контролировать токены и логировать), но можно и напрямую, если вы контролируете риски.
Пример логики: отправить сообщение с результатом (в виде HTTP‑запроса на ваш endpoint):
STATUS="$1" # success|failure
REF="$2"
curl -sS -X POST "https://your-internal-endpoint.example/api/ci/notify" \
-H "Content-Type: application/json" \
-d "{"status":"$STATUS","ref":"$REF","device":"termux"}"Внутренний endpoint можно реализовать у вас на сервере. Это помогает управлять секретами и не размещать их в репозитории.
Безопасность: секреты, доступы, минимальные права
CI/CD неизбежно использует секреты: токены реестров, ключи SSH, пароли. Подходы:
- Не храните секреты в репозитории.
- Используйте переменные окружения (в момент запуска) или файлы конфигурации, которые добавлены в
.gitignore. - Ограничивайте права ключей SSH: отдельный ключ для выгрузки артефактов с минимальными правами.
- Логируйте аккуратно: не выводите токены в консоль.
Если вы создаёте VPN только для организации локальной сети между устройствами, убедитесь, что доступ ограничен нужными диапазонами и устройствами.
Эксплуатация Termux‑агента: устойчивость и диагностика
Терминальная среда на Android подвержена особенностям питания, фоновых ограничений и сетевых прерываний. Поэтому полезны такие практики:
- Таймауты на сетевые операции (где возможно).
- Логирование в файлы артефактов: сохраняйте вывод сборки и тестов.
- Проверка свободного места: перед сборкой оценивайте объём диска.
- Повторы для отдельных операций (например, скачивание зависимостей), но аккуратно.
Пример записи логов:
mkdir -p logs
./scripts/ci/run.sh all > "logs/ci-$(date +%Y%m%d-%H%M%S).log" 2>&1При ошибке вы сможете быстро понять причину, не воспроизводя запуск вручную.
Шаблон «конвейера» под разные проекты
Ниже — краткий шаблон стадий, который вы можете адаптировать:
- Prepare: checkout, установка зависимостей.
- Build: сборка дистрибутива.
- Test: запуск тестов, сбор отчёта.
- Package: упаковка, версия по коммиту/тэгу.
- Publish: выгрузка артефактов на сервер.
- Notify: отправка статуса в чат/endpoint.
Смысл в том, чтобы Termux‑агент оставался «универсальным исполнителем», а проектные особенности были спрятаны в скриптах репозитория.
Заключение
Построение CI/CD‑конвейеров на базе Termux позволяет быстро получить исполняющую среду для сборки и тестирования, особенно когда важны мобильные сценарии, локальная инфраструктура и гибкость отладки. При правильной организации скриптов, управлении зависимостями, аккуратной публикации артефактов и внимании к безопасности вы сможете добиться предсказуемых пайплайнов и прозрачного статуса сборок.
Если вам нужно спроектировать или внедрить CI/CD‑процесс под вашу разработку (включая настройку агентской логики, структуру скриптов, артефакты и уведомления), команда РыбинскЛАБ поможет подготовить рабочую архитектуру и сопровождать эксплуатацию.