Сборки и релизы

Репозиторий проекта: https://github.com/STEALTHNET-APP/STEALTHNET-SOFTWARE. Публичный установщик выбирает последний опубликованный стабильный GitHub Release, если владелец сервера не указал конкретный тег.

Что готовит GitHub Actions

checks.yml проверяет изменения в main и pull request. release.yml запускается по тегу vX.Y.Z либо вручную для существующего тега. Тег должен точно совпадать с [workspace.package].version в Cargo.toml.

Сборки идут отдельно на ubuntu-22.04 и ubuntu-22.04-arm, нативно для x86_64 и aarch64. Базовая glibc — 2.35; сборка на более новой ОС может незаметно поднять минимальную версию glibc, поэтому менять runners без проверки поддержки нельзя. Зафиксирован Rust 1.98.1, Cargo.lock обязателен. Метаданные коммита, тега, времени, номера workflow и архитектуры попадают в бинарник API.

Пакетировщик принимает только ELF нужной архитектуры и включает:

• API, сервис подписок, бот, worker, утилиту администратора, агент ноды и шлюз кабинета;
• статику панели и инструкции установки;
• все миграции, мастер установки и обновления;
• бинарники ноды, подписок и кабинета обеих архитектур, чтобы панель amd64 могла устанавливать ARM-ноды и наоборот;
• манифест SHA256 каждого файла и внешнюю SHA256 архива.

В пакет не входят .env, db/seed.sql, тестовые аккаунты, локальная .qa-runtime, target, дампы, переписка, SSH-ключи и журналы. Пакет собирается по явному списку исходных каталогов. Не кладите приватные файлы в публичный каталог web.

Публикация версии

1. Изменить [workspace.package].version в Cargo.toml и выполнить python3 devtools/release_version.py --sync. Команда синхронизирует версии пакетов проекта в Cargo.lock, актуальные команды установки и обновления во всех инструкциях, номер версии в README и кнопки скачивания. Проверить diff и подготовить описание изменений на русском и английском, совместимости миграций и требуемых действий владельца.
2. Пройти проверки, включая чистую установку и обновление предыдущей версии. Миграции релиза должны сохранять совместимость прежних бинарников на случай возврата.
3. Создать и отправить тег vX.Y.Z в GitHub.
4. Дождаться обеих успешных сборок. Workflow создаст черновик Release, загрузит архивы и контрольные суммы.
5. Проверить описание и состав файлов, затем опубликовать черновик как стабильный релиз. Только после публикации он появится у клиентов и в проверке обновлений.

Готовые файлы релиза не перезаписываются. Исправление означает новый номер версии и новый тег. Повторный workflow для уже существующего Release остановится; не заменяйте архив под тем же тегом.

python3 devtools/release_version.py --check завершится с ошибкой, если ссылки на текущий релиз расходятся с Cargo.toml. Проверка входит в make test-release и выполняется в CI для изменений и сборок релиза. Исторические отчёты о совместимости, версии сторонних зависимостей и описания прежних исправлений сохраняют исходные номера. Новые исторические отчёты размещайте отдельно от актуальных инструкций и явно добавляйте в список исключений инструмента версий.

Пакеты:

stealthnet-vX.Y.Z-linux-amd64.tar.gz
stealthnet-vX.Y.Z-linux-amd64.tar.gz.sha256
stealthnet-vX.Y.Z-linux-arm64.tar.gz
stealthnet-vX.Y.Z-linux-arm64.tar.gz.sha256
sn-{node,sub,cabinet}-linux-{amd64,arm64}
sn-{node,sub,cabinet}-linux-{amd64,arm64}.sha256
SHA256SUMS

SHA256 защищает от повреждения и подмены относительно опубликованной суммы; доверенная точка — репозиторий и HTTPS GitHub. Ограничьте права публикации, включите 2FA, защиту main и тегов, обязательные проверки pull request. Actions закреплены по commit SHA; workflow сборки имеет только чтение, запись релиза — только отдельный job упаковки.

Локальная сборка пакетов из реальных Linux-бинарников:

python3 deploy/package-release.py --version v0.2.6 --builds /path/to/builds --output /path/to/dist

В builds/amd64 и builds/arm64 должны лежать семь перечисленных бинарников. macOS Mach-O и бинарники другой архитектуры отклоняются.

Проверки перед выпуском

make test-release проверяет парсинг параметров, защиту манифеста, секреты и сценарии управления установкой. cargo test --locked --workspace --lib --bins проверяет Rust-компоненты. Эти проверки не заменяют запуск мастера на чистой ОС с настоящими systemd и PostgreSQL.

Виртуальные машины для установочных проверок должны быть изолированы от действующего стенда. Для проверки внешнего HTTPS используйте отдельные тестовые домены и публично доступные 80/443; не перенаправляйте эти порты работающей панели ради теста.