Termux и облачные CI/CD: интеграция с GitHub Actions, Azure Pipelines и Bitbucket Pipelines через Termux‑скрипты

Termux часто используют как удобную «карманную» Linux-среду: быстро править скрипты, проверять окружение, собирать артефакты и запускать задачи. Но когда проект развивается в облачных CI/CD (GitHub Actions, Azure Pipelines, Bitbucket Pipelines), возникает логичный вопрос: как связать облако и мобильную среду так, чтобы работа была воспроизводимой и управляемой.

В этой статье покажем подход, при котором облачная система CI вызывает Termux-скрипты (через заранее настроенный канал обмена), а Termux выполняет сборку/проверки/публикацию результатов. Акцент сделан на практику, структуру, безопасность и поддерживаемость.

Концепция интеграции: Termux как исполняющая среда

Базовая идея выглядит так:

• Облако (CI/CD) запускает отправку «задания» и (при необходимости) забирает результаты.
• Termux исполняет предсказуемые скрипты: чеклист зависимостей, подготовка репозитория, запуск тестов/сборки, упаковка артефактов.
• Обмен происходит через сетевой слой (HTTP/Webhook-интерфейс, скачивание артефактов, публикация статуса). Конкретная реализация выбирается под вашу инфраструктуру.

Важно: мы говорим про интеграцию для автоматизации вашего процесса разработки. Любые внешние вызовы и доступы нужно ограничивать правами и проверками целостности.

Подготовка Termux: минимальный «каркас» рабочих скриптов

Рекомендуется заранее завести единый каркас в репозитории проекта. Например, под директорию ci/termux/:

ci/termux/
  entrypoint.sh
  install_deps.sh
  build.sh
  test.sh
  package.sh
  upload.sh

Пример entrypoint.sh — единая точка входа, которая принимает параметры и вызывает нужные шаги:

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

ACTION="${1:-all}"

case "$ACTION" in
  deps)   ./install_deps.sh ;;
  build)  ./build.sh ;;
  test)   ./test.sh ;;
  package) ./package.sh ;;
  upload) ./upload.sh ;;
  all)
    ./install_deps.sh
    ./build.sh
    ./test.sh
    ./package.sh
    ./upload.sh
    ;;
  *)
    echo "Unknown action: $ACTION"
    exit 2
    ;;
esac

Дальше можно держать каждый шаг небольшим и легко отлаживаемым. Это критично для CI: логи должны быть читаемыми, а ошибки — локализуемыми.

Сетевая связка: как сделать так, чтобы CI мог вызывать Termux

Есть несколько архитектурных вариантов. Самый практичный для командной разработки — использовать термус-агент (скрипт, слушающий запросы или периодически проверяющий очередь), и CI, который:

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

Ниже приведём схему, которая часто хорошо работает в командах: Termux принимает запросы по HTTP на локальном контуре (например, внутри вашей локальной сети) и обрабатывает их. Для доступа со стороны CI вам обычно нужен мостящий компонент (например, сервер/туннель/прокси), но ключевая часть — Termux-скрипты и их интерфейс — остаётся одинаковой.

Если вам требуется локальная сеть для тестирования, можно организовать её через VPN с целью создания локальной сети между узлами (без обхода блокировок). Конкретные детали настройки сети зависят от вашей среды.

Шаблон: Termux-скрипт, который принимает параметры и делает работу

Допустим, ваш «агент» на Termux получает параметры BRANCH и ACTION. На уровне скрипта это выглядит так:

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

BRANCH="${BRANCH:-main}"
ACTION="${ACTION:-all}"

WORKDIR="${WORKDIR:-$HOME/work}"
REPO_URL="${REPO_URL:-https://github.com/your-org/your-repo.git}"

mkdir -p "$WORKDIR"
cd "$WORKDIR"

if [ -d repo/.git ]; then
  cd repo
  git fetch --all --prune
  git checkout "$BRANCH" || git checkout -b "$BRANCH" "origin/$BRANCH"
  git pull --ff-only
else
  git clone "$REPO_URL" repo
  cd repo
  git checkout "$BRANCH" || true
fi

./ci/termux/entrypoint.sh "$ACTION"

Смысл: Termux всегда работает из воспроизводимого состояния. Облако лишь диктует, что делать, а Termux отвечает за реализацию шагов.

Интеграция с GitHub Actions: практический сценарий

Для GitHub Actions логично построить workflow, который:

• берёт код из репозитория;
• готовит параметры сборки;
• отправляет их в Termux-агент;
• забирает артефакты (или фиксирует факт завершения).

Пример workflow (адаптируйте под вашу схему доступа к Termux-агенту):

name: Termux CI

on:
  workflow_dispatch:
    inputs:
      branch:
        description: "Branch to build"
        required: true
        default: "main"
      action:
        description: "Action (deps/build/test/package/upload/all)"
        required: true
        default: "all"

jobs:
  run-termux:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Termux agent
        env:
          BRANCH: ${{ inputs.branch }}
          ACTION: ${{ inputs.action }}
          AGENT_URL: ${{ secrets.TERMUX_AGENT_URL }}
          AGENT_TOKEN: ${{ secrets.TERMUX_AGENT_TOKEN }}
        run: |
          curl -fsSL -X POST "$AGENT_URL" 
            -H "Authorization: Bearer $AGENT_TOKEN" 
            -H "Content-Type: application/json" 
            -d "{"BRANCH":"$BRANCH","ACTION":"$ACTION"}"

Здесь ключевые моменты:

• секреты хранятся в GitHub Secrets;
• токен/подпись ограничивают доступ к агенту;
• CI не исполняет тяжёлые команды на мобильной стороне — он управляет параметрами.

Чтобы результаты вернулись в облако, обычно добавляют второй этап: Termux публикует артефакты в заранее известное хранилище (например, S3/Artifact store) или отдаёт их в ответ на запрос (в зависимости от того, какой канал удобнее).

Интеграция с Azure Pipelines: шаблон с вызовом Termux

В Azure Pipelines подход аналогичен: workflow (pipeline) отправляет запрос на Termux-агент. Пример задания в YAML:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: |
    set -e
    BRANCH="$(Build.SourceBranchName)"
    ACTION="all"

    curl -fsSL -X POST "$(TERMUX_AGENT_URL)" 
      -H "Authorization: Bearer $(TERMUX_AGENT_TOKEN)" 
      -H "Content-Type: application/json" 
      -d "{"BRANCH":"$BRANCH","ACTION":"$ACTION"}"
  displayName: Trigger Termux agent

Переменные TERMUX_AGENT_URL и TERMUX_AGENT_TOKEN рекомендуется задать как секреты в переменных пайплайна/проекта. Так вы избегаете утечки доступа в логи.

Интеграция с Bitbucket Pipelines: запуск Termux-скриптов из облака

В Bitbucket Pipelines можно сделать аналогичный вызов через curl. Пример bitbucket-pipelines.yml:

image: atlassian/default-image:3

pipelines:
  default:
    - step:
        name: Trigger Termux
        script:
          - BRANCH="${BITBUCKET_BRANCH:-main}"
          - ACTION="all"
          - curl -fsSL -X POST "$TERMUX_AGENT_URL" 
              -H "Authorization: Bearer $TERMUX_AGENT_TOKEN" 
              -H "Content-Type: application/json" 
              -d "{"BRANCH":"$BRANCH","ACTION":"$ACTION"}"

Логика остаётся прежней: CI управляет параметрами, Termux исполняет шаги и фиксирует результат.

Сборка и упаковка артефактов на Termux

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

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

OUT_DIR="${OUT_DIR:-$PWD/out}"
mkdir -p "$OUT_DIR"

# Пример: упаковка сборки (адаптируйте под ваш проект)
tar -czf "$OUT_DIR/artifacts.tgz" -C build . || tar -czf "$OUT_DIR/artifacts.tgz" .

echo "Artifacts packed at: $OUT_DIR/artifacts.tgz"

Дальше upload.sh может отправить архив в ваше хранилище или вызвать callback. Важно: не публикуйте артефакты без контроля доступа.

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

OUT_DIR="${OUT_DIR:-$PWD/out}"
ARCHIVE="$OUT_DIR/artifacts.tgz"

UPLOAD_URL="${UPLOAD_URL:-https://example.com/upload}"
TOKEN="${UPLOAD_TOKEN:-}"

if [ -z "$TOKEN" ]; then
  echo "UPLOAD_TOKEN is not set"
  exit 1
fi

curl -fsSL -X POST "$UPLOAD_URL" 
  -H "Authorization: Bearer $TOKEN" 
  -F "file=@$ARCHIVE"

Если вы реализуете callback, то CI получит уведомление о статусе и сможет завершить workflow корректно.

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

• Токены и секреты: храните их в секретах CI-платформы (GitHub/Azure/Bitbucket).
• Ограничение команд: разрешайте Termux-агенту только фиксированный набор действий (например, deps/build/test/package/upload), а не произвольные команды.
• Проверка ветки/хеша: по возможности принимайте не только имя ветки, но и ожидаемый commit SHA для воспроизводимости.
• Логи: выводите подробности (версии, команды, пути), но не печатайте секреты.

Надёжность: повторяемость и таймауты

CI — это конвейер, который должен быть устойчивым. На практике добавляют:

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

На уровне скриптов помогает set -euo pipefail и аккуратная работа с путями.

Пример структуры репозитория и запуска в Termux

Удобно иметь один сценарий «как запускать вручную», чтобы быстро отлаживать до интеграции с CI:

cd /path/to/your-repo
bash ci/termux/entrypoint.sh all

А для быстрой проверки конкретного шага:

bash ci/termux/entrypoint.sh test

Так вы сокращаете время отладки: сначала подтверждаете, что Termux-скрипты работают локально, затем подключаете облако.

Заключение

Интеграция Termux с облачными CI/CD через Termux‑скрипты позволяет объединить мобильную «исполняющую» среду и управляемые процессы в GitHub Actions, Azure Pipelines и Bitbucket Pipelines. Ключ к успеху — единый интерфейс запуска на стороне Termux, безопасная сетевая связка с контролем доступа, воспроизводимые шаги сборки/тестов и понятная модель артефактов.

Если вам нужно спроектировать такую схему под ваш проект (подобрать формат обмена, реализовать агент, настроить секреты и логирование, подготовить шаблоны под ваши CI), обратитесь в РыбинскЛАБ — поможем с внедрением и сопровождением.