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

6.6 KiB

Raw Permalink Blame History

Codex: выпустить v0.1.0-alpha.20 и закрыть дыру в проверке выпуска

Репозиторий

https://github.com/ochenstarik-ui/server-monitor-manager
База: main @ 7c43977
Ветка: codex/release-alpha20
main защищён: PR обязателен, обязательны статусы build-and-test и build, force-push запрещён
один PR — одна тема; описание PR заполняется после завершения CI

Что произошло

Тег v0.1.0-alpha.19 создан на 7c43977, Release pipeline упал, релиз не опубликован. Номер сожжён и не переиспользуется — так же, как alpha.10 и alpha.11.

Причина в шаге Package bootstrap workflow linux-release.yml:

if [[ "${GITHUB_REF}" == refs/tags/* ]]; then
  sed -i "s/^PROGRAM_VERSION=.*$/PROGRAM_VERSION=\"${GITHUB_REF_NAME}\"/" "$DIST_DIR/ochenstarik-server-monitor-manager.sh"
  grep -Fq "readonly DEFAULT_RELEASE_TAG=\"${GITHUB_REF_NAME}\"" "$DIST_DIR/smm-setup.sh"
fi

Проверка требует, чтобы DEFAULT_RELEASE_TAG в deploy/smm-setup.sh совпадал с выпускаемым тегом. В main там v0.1.0-alpha.18. Проверка сама по себе правильная: она не даёт выпустить установщик, который по умолчанию тянет ассеты чужого релиза.

Дыра в другом. Весь блок закрыт условием refs/tags/*, поэтому пробный прогон через workflow_dispatch идёт по refs/heads/main и эту проверку пропускает. Репетиция перед тегированием, введённая как раз для того, чтобы не сжигать номера, не покрывает единственный шаг, который на теге и ломается. Пока это так, каждый выпуск остаётся лотереей.

Часть 1 — сделать репетицию честной

Дать linux-release.yml вход workflow_dispatch с необязательным параметром tag и выполнять при пробном прогоне те же проверки согласованности версий, что и на настоящем теге: подстановку PROGRAM_VERSION и сверку DEFAULT_RELEASE_TAG. Публикация при этом по-прежнему не выполняется — она остаётся привязанной к refs/tags/*.

Смысл: прогон workflow_dispatch с tag=v0.1.0-alpha.20 должен падать ровно там же, где упал бы настоящий тег, и по той же причине.

Если сочтёте, что вход-параметр — плохое решение, допустима альтернатива: вынести сверку согласованности версий в обычный тест, исполняемый на каждом PR, который сравнивает DEFAULT_RELEASE_TAG с последним тегом в docs/release-policy.md. Обоснуйте выбор в отчёте.

Часть 2 — привести версии в согласие

Обновить до v0.1.0-alpha.20 все места, где номер зашит. На момент написания их пять:

deploy/smm-setup.sh:6 — readonly DEFAULT_RELEASE_TAG;
deploy/smm-setup.sh:37 — текст справки SMM_TAG Release tag (default: ...);
docs/linux-bootstrap.md:9,12,13 — команды скачивания;
.github/workflows/windows-build.yml:43 — SMM_TEST_RELEASE_TAG для шага live-release.

Перечень проверьте сами: git grep -n 'alpha\.18' по deploy/, docs/, .github/. Если после обновления где-то останется старый номер, это дефект.

Заведите проверку, которая не даёт им разъехаться впредь: все зашитые упоминания версии релиза должны сверяться автоматически, а не глазами при следующем выпуске.

Часть 3 — записать судьбу alpha.19

В docs/release-policy.md: v0.1.0-alpha.19 — тег создан, Release pipeline упал на сверке DEFAULT_RELEASE_TAG, релиз не опубликован, номер не переиспользуется.

Часть 4 — выпустить

Прогнать Release pipeline через workflow_dispatch с tag=v0.1.0-alpha.20 на своей ветке и получить зелёный — теперь это осмысленная репетиция, а не формальность.
Создать и запушить тег обычным git push.
Убедиться, что релиз опубликован и что Release Verification запустился сам по workflow_run и зелёный.
Тег не двигать ни при каких обстоятельствах.

Границы

Antigravity ведёт Control и веб-консоль. Не трогать: src/**.

Ваша область: deploy/**, .github/workflows/linux-release.yml, .github/workflows/windows-build.yml в части SMM_TEST_RELEASE_TAG, tests/bootstrap/**, docs/linux-bootstrap.md, docs/release-policy.md.

Критерий приёмки

пробный прогон с параметром tag выполняет сверку версий и падает на несогласованности;
все зашитые упоминания версии обновлены до v0.1.0-alpha.20, расхождение ловится автоматически;
судьба alpha.19 записана в docs/release-policy.md;
v0.1.0-alpha.20 опубликован, набор ассетов совпадает с tests/release-verification/verify-assets.sh;
Release Verification отработал по событию и зелёный, ссылка на прогон в отчёте;
всё через PR, CI зелёный, PR не смержен до зелёного.

Отчёт

В описании PR, раздельно: что проверено локально, что в CI со ссылками на прогоны, что не проверялось и почему.

6.6 KiB Raw Permalink Blame History Unescape Escape