Автоматизация CI/CD процессов непосредственно на Android: GitLab CI Runner, Jenkins‑агенты и их конфигурация в Termux

CI/CD на Android часто воспринимают как «эксперимент», но в практических задачах это решает вполне прикладные проблемы: быстрые проверки изменений в полевых условиях, сборка легковесных проектов, тестирование скриптов, подготовка артефактов и валидация конфигураций без доступа к полноценному CI-инфраструктуре. В этой статье описан подход к автоматизации CI/CD непосредственно на Android с использованием Termux и инструментов, привычных для GitLab CI и Jenkins.

Важно: ниже рассматривается корректная настройка софта и автоматизации. Мы не обсуждаем обход блокировок или какие-либо действия, нарушающие законодательство РФ. Использование VPN упоминается только в контексте создания локальной сети (например, для доступа к внутренним ресурсам вашей инфраструктуры).

Требования и подготовка Termux

Начните с базовой подготовки среды в Termux: обновления пакетов, установки необходимых зависимостей и настройки файловой структуры под рабочие процессы CI. В большинстве случаев достаточно стандартных пакетов Termux и набора инструментов (Git, OpenSSH, Java, Docker/без Docker — по задаче).

Рекомендуемый порядок действий:

pkg update -y
pkg upgrade -y
pkg install -y git openssh-client curl ca-certificates gnupg

Далее определите, нужен ли вам Java. Для Jenkins-агента чаще всего требуется Java. Для GitLab Runner — в зависимости от того, как именно вы запускаете задачи (часто достаточно shell + нужные пакеты под конкретные сборки).

pkg install -y openjdk-17

Проверьте, что Java доступна:

java -version

Архитектура CI/CD: как Termux участвует в процессе

На Android в Termux вы обычно выступаете в роли:

исполнителя задач (runner/agent), который получает задания от CI-сервера;
рабочей среды (workspace), где выполняются команды сборки/тестирования/публикации;
клиента к репозиториям и внутренним ресурсам (через SSH/HTTPS, с учетом доступов).

С точки зрения безопасности, важно ограничить доступ, хранить секреты аккуратно (через переменные окружения CI и файлы с правами) и избегать «встроенных» паролей в скрипты.

GitLab CI Runner в Termux: реалистичный сценарий

GitLab Runner может работать в разных режимах. На Android под Termux ключевая проблема — архитектура и совместимость бинарей. На практике распространены два подхода:

Runner как отдельный процесс, если доступен сборочный/загрузочный вариант под вашу архитектуру (arm64 и т.д.) и вы готовы поддерживать бинарник;
использование GitLab CI с shell-исполнением на стороне Android через подход, когда Runner фактически запускает job в локальной среде Termux (варианты зависят от ваших ограничений и версии GitLab).

Ниже — базовая схема настройки Runner на стороне Termux, чтобы вы понимали поток работ и точки, где чаще всего делают ошибки.

Шаг 1: подготовка пользователя и директорий workspace

Создайте рабочие директории. Желательно, чтобы пути были предсказуемыми для обслуживания:

mkdir -p ~/ci/workspace
mkdir -p ~/ci/config
chmod 700 ~/ci
chmod 700 ~/ci/config
chmod 700 ~/ci/workspace

Шаг 2: регистрация runner (логика)

GitLab Runner требует регистрации с токеном и URL вашего GitLab. Обычно это делается командой регистрации. Конкретная команда может отличаться в зависимости от установленной версии бинарника, но принцип такой:

Получаете Registration Token в GitLab;
Регистрируете runner, задавая описание, теги и executor;
Запускаете runner как сервис/скрипт с учетом живучести на Android.

Примерно это выглядит концептуально:

# Пример (конкретные параметры зависят от версии gitlab-runner и executor)
gitlab-runner register \
  --non-interactive \
  --url "https://gitlab.example.local/" \
  --registration-token "REGISTRATION_TOKEN" \
  --executor "shell" \
  --description "termux-android" \
  --tag-list "android,termux" \
  --run-untagged="false" \
  --locked="false"

Если у вас еще нет gitlab-runner в Termux, сначала установите бинарник подходящей версии/архитектуры и убедитесь, что он запускается в вашей среде. При затруднениях лучше начать с минимального проверки: получение версии, пробный старт и выполнение простой команды через executor shell.

Шаг 3: конфигурация config.toml

Обычно конфигурация runner хранится в конфиг-файле. Вам важно:

Указать, где лежит workspace (или tmp), если это поддерживается вашей конфигурацией;
Задать правильные теги;
Настроить лимиты времени и поведение при простоях/перезапусках.

Условная структура config.toml:

# ~/ci/config/config.toml (примерная логика)
concurrent = 1
check_interval = 0

[[runners]]
  name = "termux-android"
  url = "https://gitlab.example.local/"
  token = "RUNNER_TOKEN"
  executor = "shell"
  shell = "bash"

  [runners.custom_build_dir]
    enabled = true
    path = "~/ci/workspace"

  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]

Пересмотрите пример под вашу фактическую конфигурацию: пути, executor и поддерживаемые секции зависят от версии Runner.

Шаг 4: пример .gitlab-ci.yml для проверки

Для первых запусков лучше использовать простую задачу (печать версий, проверка окружения, быстрые скрипты).

# .gitlab-ci.yml
stages:
  - env

env-check:
  stage: env
  tags:
    - android
    - termux
  script:
    - uname -a
    - whoami
    - java -version
    - git --version
  retry: 1

Если jobs не находят runner, чаще всего проблема в тегах, в доступности runner или в неверной регистрации URL/токена.

Jenkins‑агенты в Termux: подход и настройка

Jenkins-агент может быть реализован как подключаемый через протокол JNLP/с SSH, либо как контейнерный/псевдоагент. На Android в Termux рационально начинать с простого агентского режима, где агент выполняет shell-команды в рабочей директории Termux.

Практический сценарий:

На Jenkins создаете Node или Agent;
Генерируете ссылку/секрет для подключения;
На Android запускаете agent с нужными параметрами;
Ограничиваете ресурсы и изолируете workspace.

Шаг 1: подготовка workspace агента

mkdir -p ~/jenkins/agent
mkdir -p ~/jenkins/workspace
chmod 700 ~/jenkins/agent ~/jenkins/workspace

Шаг 2: обеспечение доступов к репозиториям

Если Jenkins будет собирать из Git, используйте SSH-ключи или доступы, заведенные на Jenkins. В Termux удобно иметь клиентскую сторону SSH.

pkg install -y openssh-client

Проверка:

ssh -V

Ключи и конфиги загружайте в Termux безопасно (например, файлом с правами chmod 600 и хранением в защищенном месте). В CI/CD не размещайте приватные ключи в репозитории.

Шаг 3: запуск Jenkins агентского процесса (концепт)

Точный способ запуска зависит от того, как вы настроили подключение (JNLP/SSH/другой механизм). Концептуально это выглядит так: вы получаете на Jenkins команду запуска (или файл агента) и запускаете его в Termux.

Обобщенный пример запуска для headless-агента (приводится как ориентир; замените переменные под ваш метод подключения):

cd ~/jenkins/agent
# Пример: скачайте agent jar / используйте команду, выданную Jenkins
# Затем запустите агент с параметрами, выданными Jenkins
java -jar agent.jar \
  -jnlpUrl "https://jenkins.example.local/computer/AGENT/slave-agent.jnlp" \
  -secret "AGENT_SECRET" \
  -workDir "~/jenkins/workspace"

Если у вас другой способ (SSH), команда инициализации будет иной. Но принцип один: агент должен стартовать, подключиться к Jenkins и дальше исполнять команды build steps.

Шаг 4: привязка задач к агенту

В Jenkins в job/пайплайне задайте метки агента (labels) или выберите нужный node. Принцип схож с GitLab tags: вы гарантируете, что сборка уходит именно на Android-агент.

Например, в Jenkins Pipeline можно ориентироваться на метки (примерно):

pipeline {
  agent { label 'android && termux' }

  stages {
    stage('Env') {
      steps {
        sh 'uname -a'
        sh 'java -version'
      }
    }
  }
}

Безопасность секретов и доступов в Termux

На Android особенно важно продумать, как хранятся секреты:

Используйте переменные окружения, заданные на стороне CI/Jenkins, а не статические значения в скриптах;
Если секреты все же лежат в файлах — задавайте права chmod 600 и минимизируйте доступ;
Ограничивайте теги/labels runner/agent так, чтобы «неавторизованные» job не попадали на Android;
Следите за логами: не выводите токены в консоль без необходимости.

Сеть и доступ к внутренним ресурсам

Чтобы сборки могли обращаться к внутренним репозиториям, артефактам и сервисам, настройте сетевую связность. Часто помогает организация локальной сети (например, через VPN для объединения сетей), чтобы Android-устройство могло достучаться до GitLab/Jenkins и внутренних хостов без публикации наружу.

Если вы используете VPN, применяйте его только для создания локальной сети и нормальной маршрутизации к вашей инфраструктуре, а не для обхода ограничений.

Практические кейсы: что запускать с Android CI

Скрипты валидации: форматирование, линтеры, проверки зависимостей;
Легковесные сборки: статические сборки, генерация артефактов, проверка Dockerfile (если не используете тяжелую сборку);
Тесты конфигураций: инфраструктурные тесты (например, Ansible/terraform validation), схемы YAML/JSON;
Сборка небольших библиотек и модулей.

Для тяжелых компиляций Android-устройство может быть медленным и более энергозатратным, поэтому чаще применяют «быстрый CI» на Android плюс «полный CI» на сервере.

Устойчивость: что учесть для надежной работы

Android подвержен ограничениям фоновой активности, смене сети и энергосбережению. Чтобы runner/agent оставались стабильными:

Используйте сценарии запуска, которые выдерживают переподключение;
Старайтесь избегать долгих фоновых задач без необходимости;
Настройте таймауты в CI, чтобы job не зависали;
Следите за логами Termux и доступностью runner/agent в момент, когда CI ожидает ответ.

Типовые ошибки и способы диагностики

Job не стартует: проверьте теги/labels, доступность runner/agent, корректность регистрации и токена;
Ошибка прав: убедитесь, что workspace и директории доступны и запись разрешена;
Проблемы с зависимостями: фиксируйте версию инструментария в скрипте (например, через пакетный менеджер Termux или установку конкретных версий);
Сеть/SSH: проверьте маршрут до GitLab/Jenkins и доступность репозиториев.

Заключение

Автоматизация CI/CD на Android с Termux — это рабочий подход для быстрых проверок, локальной валидации и поддержки сценариев «сборка рядом с полевым окружением». GitLab CI Runner и Jenkins‑агенты в такой архитектуре позволяют централизованно управлять задачами, а Android предоставляет исполнение в нужной сети и контексте. Ключ к успеху — правильная регистрация runner/agent, четкая привязка задач через теги/labels, аккуратная работа с секретами, а также учет особенностей сети и энергосбережения Android.

Хотите внедрить CI/CD на Android под ваши конкретные ограничения инфраструктуры (GitLab/Jenkins, сеть, типы проектов, требования к безопасности)? Обратитесь в РыбинскЛАБ: поможем спроектировать решение, настроить runner/агентов и сопровождать внедрение.