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>
80 lines
7.6 KiB
Markdown
80 lines
7.6 KiB
Markdown
# Antigravity: довести проверку релиза до зелёного прогона
|
||
|
||
## Состояние
|
||
|
||
`release-verification.yml` находится в `main`. Структура задания выполнена: триггеры `release: published` и `workflow_dispatch` с входным тегом, шаги проверки набора ассетов, изоляции рабочего каталога, положительной установки и негативных проверок, три отдельных скрипта под `tests/release-verification/`, `permissions: contents: read`.
|
||
|
||
Но **оба выполненных прогона `workflow_dispatch` против `v0.1.0-alpha.9` завершились отказом**, и workflow при этом оказался в `main`.
|
||
|
||
Ветка: `antigravity/release-verification-fix`, от текущего `main`.
|
||
|
||
---
|
||
|
||
## 1. Почему падает
|
||
|
||
Прогон `31419452912`, шаг `Run Positive Installation`:
|
||
|
||
```
|
||
rm -rf * .git
|
||
...
|
||
Running positive installation test for v0.1.0-alpha.9...
|
||
failed to run git: fatal: not a git repository (or any of the parent directories): .git
|
||
##[error]Process completed with exit code 1.
|
||
```
|
||
|
||
Замысел верен: рабочий каталог стирается вместе с `.git`, чтобы установка шла из релиза, а не из дерева исходников. Именно это и требовалось.
|
||
|
||
Ошибка в средстве. `run-positive-installation.sh` вызывает `gh release download`, а `gh` без явного `--repo` определяет репозиторий по git-контексту, который только что удалён. Инструмент конфликтует с изоляцией, ради которой всё и делается.
|
||
|
||
## 2. Как чинить — и почему именно так
|
||
|
||
Формально хватило бы передать `--repo ochenstarik-ui/server-monitor-manager` во все вызовы `gh`. Но правильнее убрать `gh` из проверки совсем.
|
||
|
||
Реальный пользователь на чистом сервере не имеет ни `gh`, ни `GH_TOKEN`, ни клона репозитория. Он выполняет ровно то, что описано в `docs/linux-bootstrap.md`: `curl` по публичному адресу релиза, `sha256sum`, затем `cosign` для подписи. Проверка, использующая `gh` с токеном, тестирует путь, которым никто не пользуется, и не заметит поломки публичной загрузки.
|
||
|
||
Требование: **в положительном сценарии использовать только те средства, которые есть у пользователя** — `curl`, `sha256sum`, `cosign`. Токен не использовать. Если какой-то ассет недоступен анонимным `curl`, это дефект релиза, и проверка обязана его показать.
|
||
|
||
Шаг `Verify Assets List` может продолжать пользоваться `gh` — он выполняется до изоляции и решает другую задачу.
|
||
|
||
## 3. Что вернуть в изолированный каталог
|
||
|
||
Сейчас после очистки копируется `tests/contracts/monitor-snapshot-v1.txt`. Это правильно: контракт задаёт ожидаемые значения, а не участвует в установке.
|
||
|
||
Зафиксировать это явным правилом в комментарии скрипта: из репозитория возвращаются **только ожидания** — контракты, списки, эталонные значения. Ничто исполняемое: ни установщик, ни bootstrap, ни архивы. Иначе изоляция перестаёт что-либо доказывать, а понять это по диффу будет уже нельзя.
|
||
|
||
## 4. Обязательное доказательство
|
||
|
||
Задание считается выполненным только при **зелёном прогоне `workflow_dispatch` против `v0.1.0-alpha.9`**, ссылка на прогон в отчёте.
|
||
|
||
Это тот самый случай, ради которого workflow и создавался: прогон против настоящего опубликованного релиза отвечает на вопрос, прошла бы поставка проверку или нет. Прогон против alpha.9 ценен ещё и тем, что этот релиз собран до всех недавних правок пайплайна.
|
||
|
||
Если прогон покажет дефект **релиза**, а не проверки — это успех задачи, а не провал. Зафиксировать находку отдельно и не «чинить» её ослаблением проверки.
|
||
|
||
## 5. Процесс
|
||
|
||
Изменения провести **через pull request**, не прямым коммитом в `main`.
|
||
|
||
Красный workflow попал в `main` потому, что за последние сутки шесть коммитов легли туда напрямую, минуя PR и гейт CI. Hermes параллельно включает защиту ветки: обязательный PR, обязательные статусы, запрет force-push. После этого прямой путь просто закроется.
|
||
|
||
Ветку сделать от текущего `main` — она сейчас отстаёт, в `main` вошли синхронизация переводов и правки release contract.
|
||
|
||
## Границы
|
||
|
||
Hermes ведёт `deploy/**`, `linux-release.yml`, `docs/release-policy.md`, roadmap и переводы; он же выпускает `v0.1.0-alpha.11` и чинит job `bootstrap` в релизном пайплайне.
|
||
|
||
Ваша область: `.github/workflows/release-verification.yml` и `tests/release-verification/**`. Остального не касаться; если потребуется — описать в `REPORT.md`.
|
||
|
||
## Критерий приёмки
|
||
|
||
- положительный сценарий использует только `curl`, `sha256sum` и `cosign`, без `gh` и без токена;
|
||
- в изолированный каталог возвращаются только файлы ожиданий, правило записано в скрипте;
|
||
- **зелёный прогон `workflow_dispatch` против `v0.1.0-alpha.9`**, ссылка в отчёте;
|
||
- негативные проверки по-прежнему отвергают: изменённый архив, подменённый хэш в manifest, отсутствующую подпись, подпись другой identity;
|
||
- отсутствие любого ожидаемого ассета роняет прогон;
|
||
- `actionlint` чист, вывод приложен;
|
||
- изменения внесены через PR, не прямым коммитом;
|
||
- `git diff --name-only main` не выходит за границы.
|
||
|
||
## Отчёт
|
||
|
||
Раздельно: локально, в CI со ссылками, не запускалось и почему. Описание PR заполнять после завершения CI. Если прогон против alpha.9 обнаружит дефект релиза — вынести отдельным разделом.
|