Termux стал практичной «техничкой в кармане» для сборки и тестирования кода, а также для выработки автоматизации CI/CD на стороне разработчика. Однако важный нюанс: Termux — это локальная среда, и для полноценного CI/CD обычно требуется связка с сервером оркестратора (GitLab, Jenkins, GitHub Actions) и корректная доставка артефактов/результатов.
В этой статье, как ведущий эксперт РыбинскЛАБ (Денис Усачёв), покажу подходы к автоматизированному построению кроссплатформенных CI/CD‑конвейеров в Termux с использованием GitLab‑Runner, Jenkins и GitHub Actions. Мы рассмотрим типовую архитектуру, требования к окружению, примерные конфигурации, а также рекомендации по безопасности и надежности.
Концепция: Termux как агент сборки
Реалистичная схема кроссплатформенной автоматизации выглядит так:
- CI‑сервер (GitLab / Jenkins / GitHub Actions) управляет пайплайнами.
- Termux выполняет команды сборки/тестов как агент.
- Результаты (логи, отчеты, артефакты) возвращаются в CI‑систему.
Ключевой момент — выбор механизма подключения Termux к CI‑системе. В зависимости от платформы это может быть:
- регистрация и запуск runner (GitLab Runner);
- подключение агента к Jenkins (JNLP/agent, контейнеризация — в зависимости от доступности);
- исполнение скриптов по триггеру workflow (GitHub Actions) через внешний агент (например, самоуправляемый runner или сетевой вызов, если инфраструктурно доступно).
Подготовка Termux: базовая “CI-платформа”
Для предсказуемости пайплайнов стоит заранее подготовить Termux-среду: обновление пакетов, установка базовых инструментов, настройка путей и переменных окружения.
Стартовая логика (пример):
pkg update -y && pkg upgrade -y
pkg install -y git curl wget openssh ca-certificates tar unzip zip
Дальше — зависимости под ваши сборки (язык/рантаймы). Например, если вы строите проекты на Node.js, Python или Java — устанавливайте соответствующие пакеты и фиксируйте версии (через lock-файлы в репозитории или через явные версии в Docker/скриптах, где возможно).
Практика для CI: используйте неинтерактивные команды, стабильные пути и аккуратную работу с кэшем (caching) на стороне CI.
Вариант 1: GitLab‑Runner в Termux
GitLab Runner — один из наиболее прямолинейных способов запустить задания GitLab CI на внешнем агенте. Если вы хотите, чтобы пайплайны GitLab выполнялись в Termux, вам нужно развернуть runner, зарегистрировать его в GitLab и затем ограничить его выполнение тегами.
Шаги: установка runner и регистрация
Общий план:
- Получить токен регистрации runner в GitLab;
- Установить GitLab Runner в Termux (или задействовать подходящую версию/бинарник, доступный для вашей архитектуры);
- Зарегистрировать runner и задать executor;
- Опционально: настроить кэш/артефакты через GitLab.
Примерно по смыслу (конкретные команды зависят от выбранного способа установки runner):
gitlab-runner register
# Далее интерактивно: URL, token, description, tags, executor
После регистрации важно:
- Прописать tags для runner (например,
termux). - В .gitlab-ci.yml указать, что job выполняется на runner с нужными тегами.
Пример .gitlab-ci.yml
stages:
- test
test_termux:
stage: test
tags:
- termux
script:
- echo "Running tests on Termux agent"
- ./gradlew test || true
artifacts:
when: always
paths:
- build/reports
Этот подход делает пайплайны кроссплатформенными по той причине, что оркестрация остается на стороне GitLab, а вычисления выполняются там, где доступен runner (включая Termux).
Вариант 2: Jenkins и Termux как агент
Jenkins — гибкая система, и для подключения Termux в роли агента важно выбрать модель:
- агент подключается к контроллеру Jenkins;
- либо Jenkins вызывает команды на удаленном окружении через SSH/HTTP (если инфраструктура позволяет).
Наиболее корректно рассматривать “агентный” режим, когда Termux выполняет job как внешний агент.
Подход с Jenkins agent (логика настройки)
Обычно Jenkins предоставляет способ запуска агентской части (например, Java-based agent) или JNLP/подобные механизмы. Если вы используете Termux без доступа к полноценному Java‑рантайму или ограничены совместимостью, тогда разумнее делать:
- либо “тонкий” агент (скрипт, который запускает нужные команды);
- либо Jenkins pipeline, который дергает скрипты в Termux.
Пример Jenkinsfile: вызов сценария сборки
Если Jenkins в вашей сети может вызывать Termux (например, по SSH, предварительно настроив ключи), пайплайн будет выглядеть так:
pipeline {
agent any
stages {
stage('Dispatch to Termux') {
steps {
sh '''
echo "Triggering Termux build via SSH"
ssh user@termux-host "cd ~/project && ./ci-build.sh"
'''
}
}
}
post {
always {
echo "Collect results if configured"
}
}
}
Важно: подобный вызов требует безопасной сетевой настройки. Для тестовой локальной связки можно создать локальную сеть с использованием VPN, строго для организации локального взаимодействия, а не для обхода блокировок.
Вариант 3: GitHub Actions с Termux
GitHub Actions по умолчанию исполняет jobs в GitHub-hosted окружениях или в self-hosted runners. Чтобы Termux участвовал в пайплайнах, есть два практичных подхода:
- Self-hosted runner (если Termux/устройство может выступить как runner, и у вас корректно подходит поддерживаемая архитектура);
- Внешний вызов: workflow отправляет задачу во внешнюю систему, а Termux забирает и выполняет ее скриптами.
Самый простой сценарий: “скриптовая” модель
Workflow запускает команду на удаленной машине через предусмотренный канал (например, SSH в локальной сети). Termux в этом случае — исполняющая сторона, а не полноценный runner GitHub.
name: CI via Termux
on:
push:
branches: [ "main" ]
jobs:
dispatch:
runs-on: ubuntu-latest
steps:
- name: Run build script on Termux
env:
TERMUX_HOST: ${{ secrets.TERMUX_HOST }}
TERMUX_USER: ${{ secrets.TERMUX_USER }}
TERMUX_KEY: ${{ secrets.TERMUX_KEY }}
run: |
echo "$TERMUX_KEY" > key
chmod 600 key
ssh -i key -o StrictHostKeyChecking=no ${TERMUX_USER}@${TERMUX_HOST} \
"cd ~/project && ./ci-build.sh"
В реальной эксплуатации добавляйте проверку хоста (StrictHostKeyChecking), а ключи храните только в secrets.
Унификация пайплайна: единый “контракт” для сборки
Чтобы один и тот же проект одинаково работал в GitLab/Jenkins/GitHub, полезно сделать единый контракт запуска: например, скрипт ci-build.sh, который:
- обновляет зависимости;
- собирает;
- запускает тесты;
- складывает отчеты/артефакты в предсказуемые папки.
Пример скрипта (условно):
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
echo "CI build start"
# Example for a project
# install dependencies
# npm ci
# run tests
# npm test
# gather reports
mkdir -p artifacts
# cp -r report/* artifacts/ || true
echo "CI build done"
Пайплайны в разных системах тогда становятся тонкими: они лишь вызывают этот скрипт и забирают артефакты.
Кэши и артефакты: надежность и скорость
Для скорости следует использовать кэш на стороне CI‑системы (GitLab/Jenkins/GitHub) и минимизировать “скачивание” в каждом job. В Termux лучше избегать повторной компиляции тяжелых компонентов, если это можно перенести в кэш CI или на отдельный слой (например, предварительно подготовленные зависимости).
Артефакты должны быть:
- стабильно расположены в папках;
- упакованы/нормализованы по имени;
- доступны независимо от статуса сборки (через when: always/пост‑шаги).
Безопасность: учетные данные, сеть и ключи
Рекомендации для безопасной эксплуатации:
- Храните секреты только в secret-хранилищах CI (GitLab variables / Jenkins credentials / GitHub secrets).
- Не коммитьте ключи в репозиторий.
- Для сетевого взаимодействия используйте минимум открытых портов и по возможности запускайте Termux в приватной подсети.
- Если нужно организовать соединение по локальной сети, допустимо применять VPN только для создания локальной сети между участниками (а не для обхода блокировок).
Типовые сложности и как их обходить
- Несовпадение версий инструментов: фиксируйте версии (в скрипте или через toolchain).
- Проблемы путей: используйте абсолютные пути и проверяйте переменные окружения.
- Временные сбои сети: добавляйте retry для загрузок зависимостей.
- Разные архитектуры: контролируйте совместимость бинарников и зависимостей, особенно при установке runner‑компонентов.
Заключение
Автоматизированное построение кроссплатформенных CI/CD‑конвейеров в Termux — это достижимая задача, если рассматривать Termux как агента выполнения, а CI‑систему — как оркестратор. Наиболее практичные пути: GitLab Runner для прямой интеграции, Jenkins как агент/dispatch‑модель и GitHub Actions через self-hosted подход или через безопасный внешний вызов скриптов. Унификация через единый ci-build.sh и аккуратная работа с кэшем/артефактами существенно повышают стабильность и повторяемость пайплайнов.
Если вам нужна настройка под ваш стек, аудит текущих пайплайнов и надежная схема интеграции Termux с GitLab/Jenkins/GitHub Actions — обращайтесь в РыбинскЛАБ. Мы поможем спроектировать и внедрить CI/CD‑конвейеры под реальные требования вашего проекта.