Termux — это удобная среда выполнения Linux-команд в Android, которая позволяет собирать, тестировать и запускать инструменты разработки прямо на мобильном устройстве. Однако облачные CI/CD (GitHub Actions, GitLab CI) сильны в автоматизации, воспроизводимости и управлении жизненным циклом задач: они быстро поднимают окружения, запускают сценарии, сохраняют артефакты, формируют отчеты и обеспечивают контроль качества через проверки.
Интеграция Termux с облачными CI/CD решает практическую задачу: вы получаете возможность запускать часть шагов (например, сборку/тестирование, где важно реальное Android-устройство или специфичная конфигурация) в среде Termux, сохраняя при этом преимущества облачных пайплайнов.
Важно: существует несколько архитектурных подходов. Универсального «волшебного» решения не бывает — выбор зависит от того, насколько реально у вас запускать задачи на устройстве и как вы планируете доступаться к нему из CI.
Ключевые архитектуры интеграции
Ниже — три наиболее распространенных модели, которые встречаются в проектах мобильной разработки.
1) Облачный CI управляет сценариями, а Termux выполняет задания на устройстве
В этом подходе облачный CI является «оркестратором»: он формирует команды, передает параметры и ожидает результат. Termux на Android выступает как исполнитель. Реализация может быть любой: от простого HTTP/вебхука до очередей задач и пользовательских триггеров.
Плюсы: гибкость, учет особенностей Android/Termux, можно использовать физические устройства для тестов. Минусы: требуется продумать канал связи и безопасность, а также устойчивость к обрывам сети.
2) Termux подготавливает окружение, а облачный CI делает основную сборку/тесты
Сценарии в Termux используются для настройки инструментов, подготовки кэшируемых компонентов, генерации артефактов (например, сборочных промежуточных файлов), после чего основной pipeline живет в облаке.
Плюсы: меньше сложностей с инфраструктурой, проще поддержка. Минусы: не всегда возможно «перенести» все действия в облако.
3) Комбинированный подход: часть шагов на устройстве, часть в облаке
Часто логика такова: в облаке запускается статический анализ, сборка, unit-тесты, а на Android по запросу выполняются instrumented/UI-тесты, smoke-тесты, проверка совместимости.
Плюсы: баланс качества и инфраструктурных затрат. Минусы: больше настроек.
Подготовка Termux: базовые зависимости и структура проекта
Независимо от выбранной архитектуры, важно привести Termux-окружение к воспроизводимому виду.
Практический минимум для типового сценария:
pkg update && pkg upgrade -y
pkg install -y git curl unzip tar openjdk clang
Если вы работаете с Java/Kotlin (например, Android-проекты), может понадобиться корректная версия JDK. Для Node-экосистемы — Node/npm/yarn. Для Python — Python/pip. Termux позволяет поставить нужные зависимости под ваш стек.
Рекомендуемая структура папок на устройстве:
~/ci-workspace/
workspace/
<репозиторий>/
scripts/
build.sh
test.sh
publish_artifacts.sh
На практике лучше хранить команды сборки/тестов в репозитории (или в отдельном репозитории с шаблонами) и в Termux запускать их как скрипты. Это повышает воспроизводимость и упрощает аудит изменений.
Подготовка облачного CI: контейнерные шаги и переменные
Облачный CI/CD должен уметь:
- Вызывать ваш скрипт для Termux (или поднимать задачу, которая инициирует выполнение на устройстве).
- Передавать параметры сборки/ветку/тег.
- Собирать артефакты и результаты тестов.
- Безопасно хранить секреты (токены, ключи, доступ к репозиторию, регистрационные данные).
Рекомендуется не «вшивать» секреты в код. Используйте встроенные механизмы секретов платформ:
- GitHub Actions: секрета в разделе Settings > Secrets and variables > Actions.
- GitLab CI: CI/CD Variables в настройках проекта.
Модель вызова Termux из CI: безопасные варианты
Для отправки задания на Termux вам нужен канал управления. Выбор зависит от того, есть ли у вас статический доступ к устройству.
Вариант A: Внешний endpoint (API) + инициатор на устройстве
CI отправляет HTTP-запрос на сервер (или в сервис-очередь), а Termux-процесс периодически забирает задачи. Преимущество — терминал на устройстве не обязательно «слушает входящие соединения». Главный минус — нужно поддерживать сервер/очередь.
Вариант B: Локальная сеть и запуск по внутреннему доступу
Если устройства и CI доступны в одной локальной сети (или вы организовали локальную сеть, например через VPN для создания локальной сети, строго не для обхода блокировок), можно организовать доступ по локальным адресам.
Важно: подключение к вашей локальной сети должно быть управляемым и безопасным, а доступ ограниченным по правилам файрвола/сети.
Вариант C: «Pull» модели (CI пишет задачу, Termux забирает)
Termux забирает задания из репозитория/хранилища (например, через подписанные URL или в пределах вашего инфраструктурного контура). CI записывает метаданные задачи, а устройство забирает их.
Это часто проще, чем открывать входящие порты.
Шаблон pipeline для GitHub Actions (пример оркестрации)
Ниже пример демонстрационного workflow, который инициирует удаленное выполнение. Конкретная реализация вызова (HTTP endpoint, очередь, запуск по SSH и т.п.) зависит от вашей инфраструктуры. В примере показан общий каркас.
name: mobile-ci
on:
push:
branches: [ "main" ]
pull_request:
jobs:
build-and-dispatch:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Set up job params
id: params
run: |
echo "BRANCH=${GITHUB_REF_NAME}" >> $GITHUB_OUTPUT
echo "SHA=${GITHUB_SHA}" >> $GITHUB_OUTPUT
- name: Dispatch to Termux executor
env:
TERMUX_EXEC_URL: ${{ secrets.TERMUX_EXEC_URL }}
TERMUX_TOKEN: ${{ secrets.TERMUX_TOKEN }}
run: |
curl -sS -X POST "$TERMUX_EXEC_URL"
-H "Authorization: Bearer $TERMUX_TOKEN"
-H "Content-Type: application/json"
-d '{
"ref": "${{ steps.params.outputs.BRANCH }}",
"sha": "${{ steps.params.outputs.SHA }}",
"tasks": ["build", "test"]
}'
Если ваш механизм возвращает статус/логи, добавьте шаги ожидания результата и скачивания артефактов. При необходимости — отдельное job с проверкой качества.
Шаблон для GitLab CI (пример orchestration)
Ниже — каркас job, который отправляет задачу в ваш исполнителльный контур Termux.
stages:
- dispatch
dispatch_to_termux:
stage: dispatch
image: curlimages/curl:8.7.1
script:
- |
curl -sS -X POST "$TERMUX_EXEC_URL"
-H "Authorization: Bearer $TERMUX_TOKEN"
-H "Content-Type: application/json"
-d '{
"ref": "'"$CI_COMMIT_REF_NAME"'",
"sha": "'"$CI_COMMIT_SHA"'",
"tasks": ["build", "test"]
}'
variables:
TERMUX_EXEC_URL: "$TERMUX_EXEC_URL"
TERMUX_TOKEN: "$TERMUX_TOKEN"
only:
- branches
В GitLab переменные $TERMUX_EXEC_URL и $TERMUX_TOKEN задавайте в CI/CD Variables.
Скрипты Termux: сборка и запуск тестов
Ниже пример каркаса для Termux-скриптов. Он не привязан к конкретному стеку (Gradle/Node/Python), но демонстрирует подход к структуре и логике.
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
WORKDIR="$HOME/ci-workspace/workspace"
REPO_URL="${REPO_URL:-}"
REF="${REF:-main}"
SHA="${SHA:-}"
TASKS="${TASKS:-build test}"
mkdir -p "$WORKDIR"
cd "$WORKDIR"
if [ ! -d ".git" ]; then
git clone "$REPO_URL" .
fi
git fetch --all
git checkout -f "$REF"
# Пример: сборка
if echo "$TASKS" | grep -q "build"; then
echo "=== BUILD START ==="
# Вставьте вашу команду сборки, например:
# ./gradlew assembleDebug
echo "Replace: build command here"
echo "=== BUILD END ==="
fi
# Пример: тесты
if echo "$TASKS" | grep -q "test"; then
echo "=== TEST START ==="
# Вставьте вашу команду тестов, например:
# ./gradlew test
echo "Replace: test command here"
echo "=== TEST END ==="
fi
Для получения отчетов тестов (JUnit XML, coverage, HTML-репорты) обеспечьте генерацию файлов в фиксированные директории и последующую упаковку артефактов.
Артефакты и результаты: как вернуть их в облако
Удобная практика — чтобы Termux по завершении упаковывал артефакты и отправлял их обратно в облачный CI, либо сохранял в общий объектный стор (S3-compatible) или в артефакт-хранилище.
Пример упаковки артефактов:
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
OUT_DIR="${OUT_DIR:-$HOME/ci-workspace/artifacts}"
mkdir -p "$OUT_DIR"
# Пример: упаковка результатов сборки/тестов
# zip -r "$OUT_DIR/artifacts.zip" app/build outputs reports
echo "Replace: collect artifact paths here"
# Пример: отправка (псевдо)
# curl -sS -X POST "$ARTIFACT_UPLOAD_URL" -F "file=@$OUT_DIR/artifacts.zip"
В облачном CI после выполнения вашего шага добавьте загрузку артефактов. Для GitHub Actions это можно сделать через actions/upload-artifact, для GitLab — через artifacts в конфигурации job.
Устойчивость: таймауты, повторные попытки и кэширование
Мобильные устройства чувствительнее к разрывам сети, чем облачные раннеры. Рекомендуется:
- Добавлять таймауты и ретраи на сетевые операции.
- Сохранять логи выполнения в файлы и прикреплять их как артефакты.
- Использовать кэширование зависимостей в Termux (где возможно) и в облаке (Gradle/Maven cache, npm cache и т.п.).
- Разделять pipeline на этапы: dispatch → execution → collection results.
Тестовые стратегии для реального Android: что проверять
Когда вы запускаете тесты на Termux в составе более широкого CI/CD контура, обычно выигрывает не «все подряд», а наиболее ценные проверки:
- Smoke-тест сборки: сборка APK/AAB + базовая проверка.
- Проверка совместимости (минимум сценариев) на конкретных устройствах.
- Реальные интеграционные проверки, где важна среда устройства.
- Проверка корректности версий/конфигураций (например, build flavors).
Для системных/инструментированных тестов часто подключают Android-инфраструктуру (эмуляторы или связку с тестовыми раннерами). Решение зависит от вашего технологического стека и требований к скорости.
Безопасность: секреты, токены и контроль доступа
При интеграции CI с устройством Termux ключевыми становятся безопасность и минимизация доступа:
- Храните токены только в секретах платформ CI.
- Ограничивайте endpoint исполнителя доступом по токену, IP/аудит-логами.
- Разделяйте токены по окружениям (dev/stage/prod).
- Не отправляйте приватные ключи внутрь устройства без необходимости; лучше передавать ограниченные токены на выполнение конкретных задач.
Практический чеклист внедрения
- Определите, какие шаги должен выполнять Termux: сборка, unit-тесты, smoke, instrumented/UI.
- Сформируйте набор параметров задачи: ветка/sha, конфигурация, список tasks.
- Выберите модель связи CI ↔ Termux: push (webhook), pull (очередь), локальная сеть (при необходимости).
- Обеспечьте сбор и загрузку артефактов и логов.
- Добавьте мониторинг: статусы задач, повторные попытки, алерты.
- Зафиксируйте воспроизводимость: версии инструментов, JDK/SDK, зависимости.
Заключение
Интеграция Termux с облачными CI/CD системами (GitHub Actions, GitLab CI) позволяет выстроить практичный контур непрерывной сборки и тестирования мобильных приложений с учетом особенностей Android-среды. Главное — правильно выбрать архитектуру взаимодействия, обеспечить безопасную передачу задач и результатов, а также сделать шаги сборки/тестов воспроизводимыми и наблюдаемыми.
Если вы хотите быстро и надежно организовать такой pipeline под ваш стек и инфраструктуру, РыбинскЛАБ поможет с разработкой интеграций, настройкой CI/CD, скриптов для Termux, управлением артефактами и качеством процессов.