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>
79 lines
6.6 KiB
Markdown
79 lines
6.6 KiB
Markdown
# 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`:
|
||
|
||
```bash
|
||
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 — выпустить
|
||
|
||
1. Прогнать `Release pipeline` через `workflow_dispatch` с `tag=v0.1.0-alpha.20` на своей ветке и получить зелёный — теперь это осмысленная репетиция, а не формальность.
|
||
2. Создать и запушить тег обычным `git push`.
|
||
3. Убедиться, что релиз опубликован и что `Release Verification` запустился сам по `workflow_run` и зелёный.
|
||
4. Тег не двигать ни при каких обстоятельствах.
|
||
|
||
## Границы
|
||
|
||
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 со ссылками на прогоны, что не проверялось и почему.
|