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>
106 lines
10 KiB
Markdown
106 lines
10 KiB
Markdown
# Codex: выпустить v0.1.0-alpha.14 и дать установку одной командой
|
||
|
||
Задание самодостаточно: истории работы по этому репозиторию у вас нет, всё нужное ниже.
|
||
|
||
## Репозиторий
|
||
|
||
- https://github.com/ochenstarik-ui/server-monitor-manager
|
||
- Локальный клон для этой работы: `C:\Users\Ochenstarik\projects\smm-codex`
|
||
- База: `main` @ `b0ad40c`
|
||
- Ветка: `codex/release-alpha14`
|
||
|
||
Server Monitor Manager — Windows-клиент, ASP.NET Core Control Hub, Linux-агент и WireGuard-mesh с политиками nftables. Устанавливается на серверы bash-скриптом `deploy/ochenstarik-server-monitor-manager.sh` (bootstrap), который поставляется в GitHub Release вместе с самораспаковывающимися архивами компонентов.
|
||
|
||
## Правила репозитория
|
||
|
||
- `main` защищён: PR обязателен, обязательны статусы `build-and-test` и `build`, force-push запрещён. Прямые коммиты в `main` невозможны;
|
||
- один PR — одна тема;
|
||
- описание PR заполняется **после** завершения CI, со ссылками на конкретные прогоны;
|
||
- отсутствие проверки не является дефектом отчёта; утверждение о проверке, противоречащее статусу CI, — является;
|
||
- `docs/release-policy.md` запрещает двигать опубликованные теги и заменять ассеты: исправление выпускается следующей версией;
|
||
- `.github/workflows/linux-release.yml` — единственный публикатор релизов.
|
||
|
||
## Состояние и зачем это нужно
|
||
|
||
Владелец проекта не может установить систему на свои серверы. Причина точная:
|
||
|
||
`deploy/smm-setup.sh` по умолчанию указывает на `v0.1.0-alpha.14`, которого не существует. Опубликован `v0.1.0-alpha.13`. Установка упирается в 404 на всех семи файлах релиза.
|
||
|
||
Предыстория, чтобы не повторить:
|
||
|
||
- `v0.1.0-alpha.10` и `v0.1.0-alpha.11` — теги созданы, но `Release pipeline` упал, релизы не опубликованы. Номера сожжены, переиспользовать нельзя. Оба раза причина одна: пайплайн не прогоняли перед тегированием;
|
||
- `v0.1.0-alpha.12` и `v0.1.0-alpha.13` опубликованы, но содержат `server-monitor-manager-manifest.sig` **без** `server-monitor-manager-manifest.pem`. Подпись cosign делается keyless-режимом, проверяется эфемерным сертификатом, а не постоянным ключом — без `.pem` проверить подпись невозможно. Эти релизы непроверяемы и останутся такими: политика запрещает дополнять опубликованный релиз;
|
||
- в `main` сертификат уже публикуется, `verify_archive` требует manifest, подпись и сертификат вместе. `v0.1.0-alpha.14` — первый релиз, где подпись работает целиком.
|
||
|
||
---
|
||
|
||
## Часть 1 — выпустить `v0.1.0-alpha.14`
|
||
|
||
1. **Сначала прогнать `Release pipeline` через `workflow_dispatch` на своей ветке.** Шаги публикации защищены `if: startsWith(github.ref, 'refs/tags/')` и на ветке пропускаются, но сборка, подпись и проверки выполнятся. Именно пропуск этого шага сжёг два тега подряд.
|
||
2. Создать и запушить тег `v0.1.0-alpha.14` обычным `git push` — не через `gh release create`: релиз создаёт сам workflow по событию `push: tags: v*`.
|
||
3. Сверить набор ассетов со списком в `tests/release-verification/verify-assets.sh` — он является контрактом. Обязательно должен присутствовать `server-monitor-manager-manifest.pem`.
|
||
4. Убедиться, что workflow `Release Verification` отработал **автоматически** по событию `release: published` и зелёный. Это главный результат: впервые проверка пройдёт против настоящего подписанного релиза, а не против ветки.
|
||
|
||
Если `Release Verification` найдёт дефект релиза — это успех задачи, а не провал. Зафиксировать находку отдельным разделом отчёта и не «чинить» её ослаблением проверки или флагом `SMM_ALLOW_UNSIGNED`.
|
||
|
||
**Тег не двигать ни при каких обстоятельствах.** Ошибка исправляется следующим номером.
|
||
|
||
## Часть 2 — установка одной командой
|
||
|
||
Сейчас оператор вручную скачивает семь файлов: установщик и его контрольную сумму, архив и его контрольную сумму, manifest, подпись и сертификат. Пропуск любого из трёх файлов подписи означает отказ `verify-release`. Это лишний источник ошибок в самой ответственной операции, и владелец просит одну команду.
|
||
|
||
Добавить в `deploy/smm-setup.sh`:
|
||
|
||
```
|
||
smm-setup.sh install-hub PUBLIC_HOST [HTTPS_PORT] [WG_PORT]
|
||
smm-setup.sh install-node
|
||
```
|
||
|
||
Поведение:
|
||
|
||
- определить архитектуру (`x86_64` → `linux-x64`, `aarch64`/`arm64` → `linux-arm64`) и выбрать соответствующий архив;
|
||
- скачать в рабочий каталог архив, его `.sha256`, manifest, подпись и сертификат публичным `curl` — без `gh` и без токена: у оператора их нет;
|
||
- сверить контрольную сумму архива;
|
||
- выполнить `install-control` и `mesh-init` для роли hub, либо `install-node` для роли node;
|
||
- при отсутствии любого из трёх файлов подписи — отказ с внятным сообщением, а не тихий переход на `.sha256`.
|
||
|
||
Существующий сквозной режим (`smm-setup.sh <любая-команда-bootstrap>`) сохранить: он используется в тестах и в скрипте приёмки `tests/acceptance/three-server-mesh.sh`.
|
||
|
||
Обновить `docs/linux-bootstrap.md`: короткий путь показать основным, ручной оставить ниже.
|
||
|
||
Добавить проверку в `tests/bootstrap/test-release-contract.sh`: обе новые команды существуют, отвергают лишние и недостающие аргументы, и не проходят без файлов подписи.
|
||
|
||
## Часть 3 — зафиксировать судьбу непроверяемых релизов
|
||
|
||
В `docs/release-policy.md` записать:
|
||
|
||
- `v0.1.0-alpha.10` и `v0.1.0-alpha.11` — теги без опубликованного релиза, номера не переиспользуются;
|
||
- `v0.1.0-alpha.12` и `v0.1.0-alpha.13` — опубликованы с подписью, но без сертификата, поэтому проверке подписи не поддаются;
|
||
- `v0.1.0-alpha.14` — первый полностью проверяемый релиз.
|
||
|
||
Это нужно, чтобы через полгода никто не выяснял заново, почему подпись двух релизов не сходится.
|
||
|
||
---
|
||
|
||
## Границы
|
||
|
||
Antigravity параллельно ведёт проверку подписи на стороне Desktop. **Не трогать:** `src/ServerMonitorManager.Desktop/**`, `tests/ServerMonitorManager.Desktop.Security.Tests/**`, `.github/workflows/windows-build.yml`.
|
||
|
||
Ваша область: `deploy/**`, `.github/workflows/linux-release.yml`, `tests/bootstrap/**`, `docs/linux-bootstrap.md`, `docs/release-policy.md`.
|
||
|
||
## Критерий приёмки
|
||
|
||
- `workflow_dispatch`-прогон `Release pipeline` выполнен **до** тегирования, ссылка в отчёте;
|
||
- `v0.1.0-alpha.14` опубликован, набор ассетов совпадает с `verify-assets.sh`;
|
||
- `Release Verification` отработал по событию публикации и зелёный, ссылка в отчёте;
|
||
- `install-hub` и `install-node` ставят систему без ручного скачивания файлов подписи;
|
||
- отсутствие manifest, подписи или сертификата даёт отказ, а не переход на `.sha256`;
|
||
- новые команды покрыты контрактным тестом;
|
||
- судьба alpha.10–alpha.13 записана в `docs/release-policy.md`;
|
||
- всё через PR, CI зелёный, PR не смержен до зелёного.
|
||
|
||
## Отчёт
|
||
|
||
Раздельно: что проверено локально, что в CI со ссылками на прогоны, что не проверялось и почему.
|
||
|
||
Физическая приёмка на реальных серверах в задание не входит — её выполняет владелец после выпуска релиза.
|