Интеграция Termux в CI/CD‑конвейеры: автоматический запуск GitHub Actions и GitLab CI задач на мобильном устройстве

Когда CI/CD живёт в серверной инфраструктуре, кажется, что мобильный сценарий «не нужен». Но на практике часто требуется быстро воспроизвести шаг сборки, проверить миграции БД, прогнать smoke‑тесты или скачать артефакты для диагностики прямо с устройства. Termux делает это реальным: вы превращаете телефон в удобный контроллер, а CI‑система продолжает выполнять настоящую работу в своей среде.

В этой статье рассмотрим архитектуру «мобильного CI‑клиента» на базе Termux и покажем, как автоматически запускать задачи GitHub Actions и GitLab CI с телефона, а также как корректно обрабатывать токены, логи и артефакты.

Подход: Termux как контроллер CI/CD, а не как «исполнитель» пайплайнов

Рекомендуемая схема выглядит так:

• Termux — запускает удалённые workflow/ pipelines по HTTPS, управляет параметрами, забирает статусы и результаты.
• GitHub Actions — выполняет workflow в среде GitHub, формирует артефакты и отчёты.
• GitLab CI — выполняет job в среде GitLab, сохраняет артефакты и журналы.

Так вы сохраняете производительность и воспроизводимость CI, но получаете мобильную «панель управления» и быстрый цикл проверок.

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

Для начала установите базовый набор инструментов:

pkg update && pkg upgrade -y
pkg install -y bash curl jq git

Для удобства работы с окружением создайте директорию для скриптов:

mkdir -p ~/ci-client/{github,gitlab,artifacts,scripts}

Хранение секретов: не кладём токены в открытом виде

Важно: токены GitHub/GitLab нельзя хранить в явном виде в репозитории или в скриптах, которые могут попасть в историю.

Минимально безопасный подход в Termux:

• использовать ~/.config/... вне репозитория;
• ограничить доступ к файлам;
• читать переменные окружения из файла при запуске.

Пример структуры:

mkdir -p ~/.config/ci-client
chmod 700 ~/.config/ci-client
touch ~/.config/ci-client/secrets.env
chmod 600 ~/.config/ci-client/secrets.env

В файл secrets.env добавьте:

# GitHub
export GITHUB_TOKEN='<your_token>'
export GITHUB_OWNER='<owner>'
export GITHUB_REPO='<repo>'

# GitLab
export GITLAB_TOKEN='<your_token>'
export GITLAB_PROJECT_ID='<project_id>'
export GITLAB_BASE_URL='https://gitlab.example.com'

Дальше мы будем подгружать файл в скриптах.

Запуск GitHub Actions workflow из Termux

GitHub Actions позволяет запускать workflow через workflow_dispatch. Обычно это делается через REST API. Терминальная «точка входа» — запрос на endpoint создания workflow run.

Сценарий: ручной запуск с параметрами

Создадим скрипт, который запускает workflow и печатает идентификатор запуска.

cat > ~/ci-client/github/trigger-workflow.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

source ~/.config/ci-client/secrets.env

WORKFLOW_ID='build-and-test.yml'
REF='main'

# Пример входных параметров workflow_dispatch (должны совпадать с inputs в вашем workflow)
INPUT_ENVIRONMENT='staging'
INPUT_VERSION='1.2.3'

API_URL="https://api.github.com/repos/${GITHUB_OWNER}/${GITHUB_REPO}/actions/workflows/${WORKFLOW_ID}/dispatches"

payload=$(jq -n \
  --arg ref "$REF" \
  --arg env "$INPUT_ENVIRONMENT" \
  --arg version "$INPUT_VERSION" \
  '{ref: $ref, inputs: {environment: $env, version: $version}}')

curl -sS -X POST \
  -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  -H "Accept: application/vnd.github+json" \
  "${API_URL}" \
  -d "${payload}"

echo "Workflow dispatch sent. Workflow: ${WORKFLOW_ID}, ref: ${REF}"
EOF
chmod +x ~/ci-client/github/trigger-workflow.sh

Проверка: workflow должен быть настроен с секцией on: workflow_dispatch и inputs.

Получение статуса и логов GitHub Actions

После отправки dispatch нужно определить конкретный run. Удобно — по списку runs и фильтрации по событию/ветке. Ниже пример, который забирает последние runs и показывает статус первого подходящего.

cat > ~/ci-client/github/wait-run.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

source ~/.config/ci-client/secrets.env

WORKFLOW_NAME='build-and-test.yml'
REF='main'
TARGET_STATUS='success'
TIMEOUT_SECONDS=600
SLEEP_SECONDS=10

START_TS=$(date +%s)

while true; do
  runs_url="https://api.github.com/repos/${GITHUB_OWNER}/${GITHUB_REPO}/actions/workflows/${WORKFLOW_NAME}/runs?per_page=5"

  json=$(curl -sS \
    -H "Authorization: Bearer ${GITHUB_TOKEN}" \
    -H "Accept: application/vnd.github+json" \
    "$runs_url")

  # Выбираем самый свежий run по ветке
  run_id=$(echo "$json" | jq -r --arg ref "$REF" '.workflow_runs | map(select(.head_branch == $ref)) | first | .id')
  status=$(echo "$json" | jq -r '.workflow_runs[0].conclusion // empty')

  if [[ -n "${run_id:-}" ]] && [[ -n "$status" ]]; then
    echo "Latest run id: $run_id, conclusion: $status"

    if [[ "$status" == "$TARGET_STATUS" ]]; then
      echo "Done: success"
      break
    fi
    if [[ "$status" == 'failure' || "$status" == 'cancelled' || "$status" == 'timed_out' ]]; then
      echo "Done: terminal state = $status"
      break
    fi
  else
    echo "Run not ready yet..."
  fi

  now=$(date +%s)
  if (( now - START_TS > TIMEOUT_SECONDS )); then
    echo "Timeout waiting for workflow run"
    exit 1
  fi

  sleep "$SLEEP_SECONDS"
done
EOF
chmod +x ~/ci-client/github/wait-run.sh

Для скачивания артефактов GitHub Actions обычно требуется отдельный шаг: либо API с артефактами, либо использование download-artifact из workflow. На практике удобно, чтобы workflow сохранял артефакты, а Termux забирал их по API.

Запуск GitLab CI pipeline из Termux

В GitLab для триггера pipeline используются API. Наиболее распространённый вариант — endpoint /trigger/pipeline с триггер‑токеном (проще для «клиента»), и вариант запусков через обычный API с личным токеном.

Рассмотрим запуск через API pipelines (универсально, работает при наличии токена с нужными правами).

Сценарий: запускаем pipeline по branch

cat > ~/ci-client/gitlab/trigger-pipeline.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

source ~/.config/ci-client/secrets.env

REF='main'
PIPELINE_VARIABLES_JSON='{"ENVIRONMENT":"staging","VERSION":"1.2.3"}'

# Пример endpoint:
# POST /projects/:id/pipeline?ref=<branch>
url="${GITLAB_BASE_URL}/api/v4/projects/${GITLAB_PROJECT_ID}/pipeline?ref=${REF}"

# Преобразуем JSON в формат variables для GitLab
variables_args=$(echo "$PIPELINE_VARIABLES_JSON" | jq -r 'to_entries[] | "variables["+ .key + "]=\"" + .value + "\""' | paste -sd '&' -)

response=$(curl -sS -X POST \
  -H "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  -H "Accept: application/json" \
  "$url" \
  -d "${variables_args}")

echo "$response" | jq -r '.id, .web_url'
EOF
chmod +x ~/ci-client/gitlab/trigger-pipeline.sh

Важно: переменные, которые вы отправляете, должны соответствовать тому, как вы читаете их в .gitlab-ci.yml. В противном случае pipeline запустится, но шаги могут игнорировать значения.

Ожидание завершения и просмотр статуса

Пайплайн имеет идентификатор. Termux может периодически опрашивать статус.

cat > ~/ci-client/gitlab/wait-pipeline.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

source ~/.config/ci-client/secrets.env

PIPELINE_ID="${1:-}"
if [[ -z "$PIPELINE_ID" ]]; then
  echo "Usage: $0 <pipeline_id>"
  exit 1
fi

TIMEOUT_SECONDS=600
SLEEP_SECONDS=10
START_TS=$(date +%s)

while true; do
  url="${GITLAB_BASE_URL}/api/v4/projects/${GITLAB_PROJECT_ID}/pipelines/${PIPELINE_ID}"

  status_json=$(curl -sS \
    -H "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
    -H "Accept: application/json" \
    "$url")

  status=$(echo "$status_json" | jq -r '.status')
  echo "Pipeline $PIPELINE_ID status: $status"

  case "$status" in
    success|failed|canceled|skipped)
      break
      ;;
  esac

  now=$(date +%s)
  if (( now - START_TS > TIMEOUT_SECONDS )); then
    echo "Timeout waiting for GitLab pipeline"
    exit 1
  fi

  sleep "$SLEEP_SECONDS"
done

web_url=$(echo "$status_json" | jq -r '.web_url')
echo "Result: $web_url"
EOF
chmod +x ~/ci-client/gitlab/wait-pipeline.sh

Автоматизация «одной кнопкой»: единый скрипт для GitHub и GitLab

Чтобы запуск с телефона был одинаковым для разных платформ, можно сделать унифицированный интерфейс. Ниже — концептуальный пример: скрипт запускает либо GitHub workflow, либо GitLab pipeline.

cat > ~/ci-client/scripts/mobile-ci.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

MODE="${1:-}"   # github|gitlab
REF="${2:-main}"
ENVIRONMENT="${3:-staging}"
VERSION="${4:-1.0.0}"

case "$MODE" in
  github)
    echo "Trigger GitHub Actions..."
    # Здесь можно адаптировать параметры под ваш workflow_dispatch
    ~/ci-client/github/trigger-workflow.sh
    ;;
  gitlab)
    echo "Trigger GitLab CI..."
    # Для примера просто запускаем и выводим ID/URL
    out=$(~/ci-client/gitlab/trigger-pipeline.sh | cat)
    pipeline_id=$(echo "$out" | head -n1)
    ~/ci-client/gitlab/wait-pipeline.sh "$pipeline_id"
    ;;
  *)
    echo "Usage: $0 github|gitlab [ref] [environment] [version]"
    exit 1
    ;;
esac
EOF
chmod +x ~/ci-client/scripts/mobile-ci.sh

Артефакты и результаты: как «забрать результат» из CI в Termux

С практической точки зрения удобнее, когда workflow/job:

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

Далее Termux может:

• скачать артефакт по API;
• или показать ссылку web_url на run/pipeline, чтобы вы открыли лог на телефоне;
• или (при необходимости) скачать только ключевые файлы.

На уровне реализации конкретные endpoint’ы зависят от выбранного механизма публикации артефактов (GitHub Upload artifact / GitLab artifacts). Важно придерживаться одного стандарта в проектах, чтобы мобильный клиент был универсальным.

Сеть и доступ: где может понадобиться локальная сеть

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

В остальном для вызовов GitHub/GitLab вам достаточно HTTPS и стандартной мобильной связи.

Рекомендации по безопасности и надёжности

• Минимизируйте права токенов. Используйте отдельные токены под задачу и с нужными scope.
• Ограничивайте параметры. Валидация входов в workflow/pipeline снизит риск «неожиданного поведения».
• Добавляйте явные таймауты и ретраи в скриптах (сетевые запросы с мобильных сетей бывают нестабильны).
• Логируйте локально ключевые шаги (но не токены).
• Разделяйте окружения (staging/production) через отдельные inputs/переменные.

Типовой рабочий процесс для разработчика

1. Вносите изменения в ветку.
2. С телефона запускаете workflow/pipeline с параметрами (например, environment=staging).
3. Скрипт показывает итоговый статус.
4. По необходимости вы открываете web_url и/или скачиваете конкретные артефакты.

Результат — вы быстрее получаете обратную связь и быстрее закрываете баги.

Заключение

Termux отлично подходит на роль мобильного CI/CD‑клиента: он безопасно инициирует удалённые GitHub Actions и GitLab CI задачи по API, управляет входными параметрами и помогает оперативно проверять статус и результаты. Правильное хранение секретов, стандартизация входов/артефактов и аккуратная работа со статусами превращают телефон в удобный инструмент для отладки и контроля качества.

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