23eb3f5233
Задания, отчёты и патчи, лежавшие в C:\Users\Ochenstarik\projects и в домашней папке, перенесены в agents/. Разложено по агентам там, где имя файла позволяло определить автора; остальное — в _salvage-2026-08-18/ и разбирается вручную. Патчи в notes/salvage-2026-08-18/ — незакоммиченная работа из брошенных рабочих копий: она существовала только на диске. Тяжёлое (релизные архивы, инсталляторы, наборы данных) в репозиторий не попало: оно лежит рядом, в Agent_projects/_archive и Agent_projects/_data. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
109 lines
8.2 KiB
Markdown
109 lines
8.2 KiB
Markdown
# Antigravity: проверка опубликованного релиза установкой
|
||
|
||
## Состояние
|
||
|
||
`main` @ `61471f0`. Открытых PR нет. Очередь B подписанной поставки слита (#35), все замечания по ней закрыты.
|
||
|
||
Задание относится к завершению Горизонта 0 — это проверка того, что уже сделано, а не новая функциональность. Гейт горизонта не нарушается.
|
||
|
||
Ветка: `antigravity/release-verification`.
|
||
|
||
---
|
||
|
||
## Часть 1 — установка из опубликованного релиза как проверка в CI
|
||
|
||
### Зачем
|
||
|
||
Вся цепочка поставки собрана: manifest v2, подпись cosign, проверка в bootstrap и в Desktop, воспроизводимые сборки. Но **ни один автоматический тест не устанавливает систему из фактически опубликованного релиза.**
|
||
|
||
Цена этого пробела уже известна. При первой живой установке нашлись подряд:
|
||
|
||
- `alpha.8` был опубликован вообще без Linux-архивов — единственной поддерживаемой серверной платформы;
|
||
- `verify_archive` искал в manifest ключ `ServerMonitorManager-linux-x64.tar.gz`, тогда как ассет называется `server-monitor-manager-linux-x64.tar.gz`, и захардкоженную архитектуру — то есть проверка подписи ломала штатную установку;
|
||
- release-workflow трижды падали на CycloneDX и путях артефактов.
|
||
|
||
Ни одно из этого не ловилось зелёным CI, потому что CI проверяет **сборку из дерева**, а не **релиз как продукт**. Тесты работают с локально собранным архивом; настоящие имена ассетов, настоящий manifest и настоящая подпись в них не участвуют.
|
||
|
||
### Что сделать
|
||
|
||
Новый workflow, запускаемый после публикации релиза и вручную через `workflow_dispatch` с параметром тега.
|
||
|
||
На чистом runner'е, без доступа к дереву исходников кроме самого скрипта установки:
|
||
|
||
1. Скачать `smm-setup.sh` из релиза по тегу и проверить его контрольную сумму по опубликованному `.sha256`.
|
||
2. Запустить `smm-setup.sh hub <локальный-хост>` — то есть пройти ровно тот путь, которым пользуется владелец: загрузка bootstrap и архива из релиза, проверка контрольных сумм, проверка подписи manifest, `preflight`, `verify-release`, установка Control, `mesh-init`.
|
||
3. Проверить, что Control активен и `/healthz` отвечает.
|
||
4. Выпустить код Node через `node-code`, установить Node на той же машине, дождаться активного `ochenstarik-smm-agent.service` и выданного сертификата.
|
||
5. Проверить `install-monitor`: пользователь создан, forced command выдаёт снимок, поля совпадают с `tests/contracts/monitor-snapshot-v1.txt`.
|
||
6. Снять всё через `uninstall-*` и убедиться, что следов не осталось.
|
||
|
||
Требования:
|
||
|
||
- скрипт установки берётся **из релиза**, а не из рабочего дерева — иначе проверяется не то, что получит пользователь;
|
||
- проверка подписи не обходится: `SMM_ALLOW_UNSIGNED` в этом прогоне не используется;
|
||
- прогон падает, если в релизе отсутствует любой ожидаемый ассет.
|
||
|
||
### Негативные проверки
|
||
|
||
Отдельными шагами, каждый обязан завершиться отказом установки:
|
||
|
||
- архив с изменённым байтом;
|
||
- manifest с подменённым хэшем без переподписи;
|
||
- manifest без файла подписи;
|
||
- подпись, сделанная другой identity.
|
||
|
||
Первые три уже покрыты юнит-тестами против синтетических данных; здесь они проверяются на настоящем релизе и настоящем cosign.
|
||
|
||
---
|
||
|
||
## Часть 2 — проверка того, что релиз полон
|
||
|
||
Отдельный шаг того же workflow: сверить набор ассетов релиза с ожидаемым списком и упасть при расхождении.
|
||
|
||
```
|
||
ochenstarik-server-monitor-manager.sh(+.sha256)
|
||
server-monitor-manager-linux-x64.tar.gz(+.sha256)
|
||
server-monitor-manager-linux-arm64.tar.gz(+.sha256)
|
||
server-monitor-manager-linux-x64-sbom.json
|
||
server-monitor-manager-linux-arm64-sbom.json
|
||
server-monitor-manager-win-x64-sbom.json
|
||
ServerMonitorManager-win-x64.msix
|
||
ServerMonitorManager-test-signing.cer
|
||
SHA256SUMS
|
||
smm-setup.sh(+.sha256)
|
||
server-monitor-manager-manifest.json
|
||
server-monitor-manager-manifest.sig
|
||
```
|
||
|
||
Ровно этой проверки не хватало, когда `alpha.8` вышел без Linux-архивов и это заметил человек, а не CI.
|
||
|
||
---
|
||
|
||
## Границы
|
||
|
||
Hermes параллельно выпускает `v0.1.0-alpha.10`, правит `deploy/smm-setup.sh` (значение `DEFAULT_RELEASE_TAG`), roadmap, переводы README и удаляет слитые ветки. Может также добавить Debian VM в матрицу.
|
||
|
||
**Не трогать:** `deploy/**`, `docs/roadmap.md`, `docs/i18n/**`, `docs/linux-platform-matrix.md`.
|
||
|
||
Ваша область — новый workflow и вспомогательные скрипты проверки под `tests/`. Если для задачи потребуется изменить существующий workflow, согласовать: релизный пайплайн ведёт Hermes, и три починки подряд за день случились именно из-за правок с двух сторон.
|
||
|
||
## Чего опасаться
|
||
|
||
Новый workflow по определению не запускается на pull request — он привязан к публикации релиза. Зелёный PR про него ничего не докажет, ровно как было с `permissions` и `locked-mode`.
|
||
|
||
Поэтому обязательно: `actionlint` на новом файле с выводом в отчёт и прогон через `workflow_dispatch` на своей ветке против уже существующего тега `v0.1.0-alpha.9`. Это заодно ответит на главный вопрос — прошла бы проверка на реальном релизе или нет.
|
||
|
||
## Критерий приёмки
|
||
|
||
- новый workflow выполняет полный цикл установки из опубликованного релиза и снимает её;
|
||
- четыре негативные проверки отвергают установку;
|
||
- отсутствие любого ожидаемого ассета роняет прогон;
|
||
- `SMM_ALLOW_UNSIGNED` в основном прогоне не используется;
|
||
- `actionlint` чист, вывод приложен;
|
||
- выполнен `workflow_dispatch`-прогон против `v0.1.0-alpha.9`, ссылка в отчёте;
|
||
- `git diff --name-only main` не содержит файлов из списка границ;
|
||
- PR не смержен.
|
||
|
||
## Отчёт
|
||
|
||
Раздельно: локально, в CI со ссылками, не запускалось и почему. Описание PR заполнять после завершения CI.
|