Ochenstarik 23eb3f5233 chore(agents): разбор рабочих папок с диска на 2026-08-18

Задания, отчёты и патчи, лежавшие в 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>

2026-08-18 14:19:54 +07:00

7.6 KiB

Raw Permalink Blame History

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 обнаружит дефект релиза — вынести отдельным разделом.

7.6 KiB Raw Permalink Blame History Unescape Escape