[Task] Настройка CI/CD Workflow для сборки и автоматизированного тестирования CLI #10

Контекст

Для обеспечения стабильности инструментов автоматизации необходимо внедрить Pipeline, который будет проверять работоспособность CLI-утилиты при каждом Push или Pull Request. Это предотвратит регрессии в процессе настройки окружения (env setup) и гарантирует, что Core-пакет Docker всегда собирается без ошибок. Автоматизация тестирования CLI критична, так как ошибки в скриптах инициализации блокируют работу всей команды.

Технические требования

• Локация логики: .github/workflows/ci.yml, scripts/tests/cli.test.ts
• Инструменты: GitHub Actions, Docker, Jest/Vitest (для тестов), ShellSpec (для проверки shell-алиасов).
• Логика работы:
  1. Trigger: Запуск при push в main, develop и любых PR.
  2. Job: Build: Сборка Docker-образов бэкенда и аналитики для проверки валидности Dockerfile.
  3. Job: Lint: Проверка кода CLI на соответствие стандартам (ESLint/Prettier).
  4. Job: CLI-Test:
     • Эмуляция пользовательского ввода (использование yes или моков для inquirer).
     • Проверка создания файла .env из .env.example.
     • Проверка валидации некорректных данных (например, букв в поле порта).

Цель и критерии приемки (Definition of Done)

• База: Создан файл workflow в .github/workflows, настроены базовые шаги (checkout, setup-node, install deps).
• Функционал: Реализован интеграционный тест для CLI, который проверяет: npm run env:setup -- --verify.
• Функционал: Добавлена проверка сборки Docker-контейнеров через docker-compose config на этапе CI.
• Лимиты/SLA: Полный цикл прохождения CI (сборка + тесты) не должен превышать 5-7 минут.
• Интеграция: Настроены Slack/Telegram уведомления о статусе билда (опционально) и блокировка слияния PR при упавших тестах.

Важные указания

• Производительность: Использовать actions/cache для node_modules и слоев Docker, чтобы ускорить повторные запуски.
• Ошибки: Workflow должен падать с информативным логом, если CLI не прошел валидацию или Docker-образ не собрался из-за синтаксических ошибок.
• Безопасность: Использовать secrets.GITHUB_TOKEN для операций внутри репозитория. Не передавать реальные переменные окружения в логи CI при тестировании CLI.