Создание мобильного CI/CD пайплайна в Termux: от Git‑репозитория до деплоя в облако через GitHub Actions и GitLab Runner

Когда вы тестируете идею, поднимаете прототип сервиса или поддерживаете небольшую инфраструктуру, удобно иметь «мобильное рабочее место», которое может быстро собрать проект, проверить качество и подготовить артефакты. Termux в этом случае превращается в портативную среду выполнения: вы можете выполнять команды сборки, запускать тесты, формировать артефакты и синхронизировать изменения с репозиторием.

Важно понимать границу ролей: CI/CD как правило исполняется в инфраструктуре CI (GitHub Actions / GitLab Runner). Termux же выступает как источник изменений (и при необходимости — как место локальной сборки/подготовки). Такой подход снижает трение в процессе разработки и ускоряет обратную связь.

Архитектура решения: Termux + GitHub Actions + GitLab Runner + облако

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

• Termux: создание/актуализация кода, локальная сборка (опционально), коммиты и пуш в Git‑репозиторий.
• GitHub Actions: CI (линтинг, тесты, сборка) и публикация артефактов (например, в релиз или в пакетный реестр).
• GitLab Runner: CD (выполнение деплоя по триггеру: по новому артефакту/релизу или по изменению ветки).
• Облако: прием артефакта и развертывание (контейнеры, VM, статические файлы — в зависимости от вашей модели).

Главная идея: Termux обеспечивает мобильный цикл «написал → проверил → закоммитил», а CI/CD выполняется в контролируемой среде.

Подготовка Termux: зависимости, Git и базовая настройка

Начнем с минимального набора инструментов. В Termux используются системные пакеты и зависимости из репозиториев Termux.

pkg update -y
pkg upgrade -y
pkg install -y git openssh curl wget ca-certificates

Далее — установка языка и инструментов сборки под ваш проект (ниже примеры). Вы выбираете то, что соответствует вашему стеку.

Пример: Node.js

pkg install -y nodejs-lts npm

Пример: Python

pkg install -y python

Пример: Java (если нужно)

pkg install -y openjdk-17

Проверка инструментов:

git --version
node -v
python --version

Создание Git‑репозитория в Termux

Перейдите в рабочую папку и инициализируйте репозиторий.

mkdir -p ~/work/my-app
cd ~/work/my-app
git init

Добавьте базовую структуру проекта. Если у вас уже есть код — просто поместите его в эту папку.

Создайте .gitignore (примерно для популярных стеков):

cat > .gitignore << 'EOF'
node_modules/
dist/
build/
.env
*.log
EOF

Добавьте файлы и сделайте первый коммит:

git add .
git commit -m "Initial commit"

Подключение к удаленному репозиторию (GitHub и/или GitLab)

Чтобы CI запускался автоматически, репозиторий должен быть доступен из GitHub и/или GitLab. Самый практичный вариант — создать репозиторий в GitHub (для GitHub Actions) и настроить зеркало/второй remote в GitLab (для GitLab Runner), либо использовать один Git-платформенный источник событий и вторую платформу только как исполняющую среду для деплоя.

Вариант 1: один remote (например, GitHub) — и Actions выполняют CI, а деплой можно организовать через Runner (например, по артефактам/релизам).

Вариант 2: два remote — GitLab Runner получает событие/артефакт из GitLab. Это полезно, если вы хотите, чтобы CD управлялся в GitLab.

Добавление remote:

git remote add origin git@github.com:YOUR_ORG/YOUR_REPO.git
git remote -v

Пуш:

git branch -M main
git push -u origin main

Аутентификация: для безопасности используйте SSH‑ключи или токены в формате, поддерживаемом платформой. Не храните секреты в репозитории.

Опционально: локальная сборка/тесты в Termux перед пушем

Чтобы сократить время цикла, выполняйте минимальный набор проверок локально в Termux. Ниже примеры в зависимости от стека.

Пример: Node.js

npm ci
npm test
npm run build

Пример: Python

python -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
pytest

После успешных проверок делайте коммит и пуш:

git add .
git commit -m "Add feature and tests"
git push

CI в GitHub Actions: сборка, тесты и публикация артефакта

Создайте файл конфигурации в репозитории GitHub: .github/workflows/ci.yml.

Ниже пример для Node.js. При необходимости адаптируйте команды под ваш проект.

name: CI

on:
  push:
    branches: [ "main" ]
  pull_request:

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-build
          path: dist

Результат: при каждом push в main Actions запускают сборку, тесты и публикуют артефакт. Следующий шаг — доставка этого артефакта в CD-процесс.

Передача артефакта между CI и CD

Есть несколько рабочих паттернов. Выбор зависит от того, как у вас организованы GitHub и GitLab.

• Через GitHub Releases: CI создает релиз, прикрепляет файл(ы), а CD (на стороне GitLab Runner) качает артефакт по тегу.
• Через пакетное хранилище/регистры: артефакт публикуется в регистр (container registry или artifact storage), а Runner берет его по версии.
• Через промежуточное хранилище: S3/Blob Storage и т.п. (секреты кладутся в переменные окружения CI/CD).

Для примера ниже рассмотрим релиз‑ориентированный подход.

CD в GitLab Runner: деплой в облако

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

• установлен на выделенной машине/VM;
• или развернут в Kubernetes;
• или это может быть отдельный self-hosted runner для деплоя.

Деплой должен выполняться командой, которая умеет принимать артефакт и обновлять приложение. Часто это:

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

Пример .gitlab-ci.yml для деплоя через SSH (упрощенный). Вам нужно адаптировать команды под ваш облачный провайдер и способ развертывания.

stages:
  - deploy

deploy:
  stage: deploy
  image: alpine:3.20
  only:
    - main
  variables:
    GIT_STRATEGY: none
  before_script:
    - apk add --no-cache openssh-client curl
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" | tr -d '
' > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - ssh-keyscan -H "$DEPLOY_HOST" >> ~/.ssh/known_hosts
  script:
    # пример: скачивание артефакта (как именно — зависит от выбранного хранилища)
    - curl -L "$ARTIFACT_URL" -o app.zip
    # пример: деплой по SSH
    - scp app.zip "$DEPLOY_USER@$DEPLOY_HOST:/tmp/app.zip"
    - ssh "$DEPLOY_USER@$DEPLOY_HOST" "deploy-script /tmp/app.zip"

Секреты не пишите в репозиторий. Используйте переменные GitLab CI/CD: SSH_PRIVATE_KEY, DEPLOY_HOST, DEPLOY_USER, ARTIFACT_URL.

Настройка секретов и принцип минимальных прав

Чтобы пайплайн был безопасным:

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

В Termux следите, чтобы .env не попадал в git (через .gitignore).

Проверка пайплайна: сценарии отладки

Если CI не стартует или деплой не работает, проверьте по порядку:

1. Триггеры: ветка main, наличие правильного пути к файлу workflow.
2. Зависимости: соответствие версии языка (Node/Python/Java).
3. Артефакты: корректный path в upload-artifact и/или правильный механизм получения артефакта на CD.
4. Секреты: заполнены ли переменные в GitLab CI и существуют ли они на Runner окружении.
5. Сетевые доступы (не для обхода блокировок): при необходимости убедитесь, что Runner имеет доступ к целевому ресурсу в облаке/на сервере.

Практический сценарий “от телефона до деплоя”

Типичный рабочий день выглядит так:

1. В Termux вы обновляете код, выполняете быстрые тесты, делаете коммит.
2. Пуш в GitHub триггерит GitHub Actions: собирается проект и формируется артефакт.
3. После успешного CI создается публикация/передача артефакта (релиз/хранилище/registry).
4. GitLab Runner по правилам CD получает событие и деплоит в облако с обновлением сервиса.

Если вы управляете этим процессом через релизы/версии, вы получаете воспроизводимость: всегда можно повторить деплой конкретной версии.

Рекомендации по структуре репозитория

Чтобы пайплайн был проще поддерживать:

• храните CI/CD конфигурации в стандартных путях (.github/workflows, .gitlab-ci.yml);
• разделяйте шаги сборки и деплоя на отдельные скрипты (например, shell‑скрипты в scripts/);
• добавляйте версии артефактов (тег, build number);
• ведите changelog или используйте семантическое версионирование, если оно уместно.

Заключение

Мобильный цикл разработки в Termux позволяет быстро создавать и обновлять код, а связка GitHub Actions + GitLab Runner — надежно реализовать CI/CD до деплоя в облако. Такой подход дает контролируемые этапы: Termux ускоряет подготовку изменений, а CI/CD платформы отвечают за воспроизводимость сборок, тестов и развертывания.

Если хотите настроить пайплайн под ваш стек (контейнеры, VM, статические сайты, серверные API) и правильно разнести роли, секреты и артефакты, обратитесь в РыбинскЛАБ — поможем спроектировать и внедрить процесс CI/CD «под ключ».