petr.polezhaev
a03458f9bc
- critical: README честно описывает HACS (только публичный GitHub-зеркало)
+ ручная установка копированием; RELEASE_HA — шаг зеркала и codeowners
- critical: ESPHome-канал приёмки реализован реально (aioesphomeapi:
connect/list_entities/climate_command для режима и уставки; fan/swing —
только HA); unit-тест на фейковом модуле
- major: quick/long восстанавливают исходное состояние в finally даже при
сбое; quick ждёт восстановления; ошибки шага пишутся в результат (rc 1),
а не фаталят (rc 2)
- major: RELEASE_HA — manylinux через auditwheel repair (PyPI отклоняет
linux_x86_64), build/twine, aarch64, корректные проверки .so, тег/версия
- major: полный ключ для ESPHome теперь реально виден в options flow
(«Настройка» на карточке интеграции, поле LAN IP key, можно заменить) —
README/diagnostics синхронизированы
- minor: non-JSON ответ → rc 2; CSV quick+long и инкрементальная запись;
допуск _matches в long; --settle-timeout; hacs.json homeassistant=2025.1;
brand/{icon,logo}.png заглушки; план §6/§7 уточнён
- тесты: acceptance self-test 11 (restore-after-failure, long fail, non-JSON,
esphome channel), options flow (2), всего 28+11+49
80 lines
4.9 KiB
Markdown
80 lines
4.9 KiB
Markdown
# Чек-лист релиза HA-интеграции (H5)
|
||
|
||
## 1. Публикация pyfglair (PyPI)
|
||
|
||
Манифест компонента требует `pyfglair>=1.0.0`; штатный installer HA
|
||
резолвит требования только через PyPI. PyPI (warehouse) принимает только
|
||
`manylinux*`/`musllinux*` платформенные теги — локальный
|
||
`py3-none-linux_x86_64` будет отклонён (`HTTP 400 unsupported platform
|
||
tag`), поэтому wheel нужно «починить» auditwheel'ом в контейнере со старой
|
||
glibc (manylinux):
|
||
|
||
```sh
|
||
pip install build auditwheel twine
|
||
|
||
# для каждой архитектуры (linux x86_64/aarch64) в manylinux-контейнере
|
||
# (например, quay.io/pypa/manylinux2014_<arch>):
|
||
python -m build --wheel # .so без внешнего mbedcrypto
|
||
auditwheel repair dist/pyfglair-*.whl \
|
||
--plat manylinux2014_x86_64 -w dist/ # или manylinux_2_28 и т.п.
|
||
python -m build --sdist # sdist с C++-исходниками (MANIFEST.in)
|
||
twine upload dist/*
|
||
```
|
||
|
||
Проверки перед публикацией:
|
||
|
||
* `scripts/py-ci.sh` — pyfglair + acceptance self-test + components;
|
||
* `scripts/ci.sh` — ядро (gcc/clang, ASan/UBSan) 11/11;
|
||
* `readelf -d build-pyfglair/libfgl-aircon.so*` (или распакованный wheel:
|
||
`pyfglair/libfgl-aircon.so*`) — нет внешней `libmbedcrypto` (встроен);
|
||
* `auditwheel show` для repaired-wheel — тег manylinux и только
|
||
базовые системные библиотеки;
|
||
* установка wheel в чистый venv вне репозитория:
|
||
`python -c "import pyfglair.session"`;
|
||
* aarch64: сборка в соответствующем manylinux-контейнере (QEMU или
|
||
нативная), иначе пользователи ARM не смогут поставить `pyfglair`.
|
||
|
||
Альтернатива — cibuildwheel (`pip install cibuildwheel`) с `auditwheel
|
||
repair` внутри, но текущий `bdist_wheel`-хук отдаёт тег
|
||
`py3-none-<plat>`, поэтому проверяйте итоговые теги вручную.
|
||
|
||
## 2. GitHub-зеркало и HACS
|
||
|
||
HACS устанавливает интеграции только с публичных **GitHub**-репозиториев
|
||
(GitLab/Gitea не поддерживаются). Шаги:
|
||
|
||
* создать GitHub-зеркало (push mirror) и убедиться, что оно содержит
|
||
`custom_components/fglair/`, `hacs.json`, тег релиза;
|
||
* заполнить `codeowners` в `custom_components/fglair/manifest.json`
|
||
(GitHub-хендлы; сейчас пустой список);
|
||
* проверить `documentation`/`issue_tracker` в манифесте;
|
||
* обновить `version` манифеста под номер тега (сейчас `0.1.0`, pyfglair —
|
||
`1.0.0`; синхронизируйте по вкусу — компонент и пакет версионируются
|
||
отдельно);
|
||
* заменить заглушки `custom_components/fglair/screenshots/step-N.png`
|
||
реальными скриншотами (описания «что должно быть видно» — в README);
|
||
* заменить заглушки `custom_components/fglair/brand/{icon,logo}.png`
|
||
фирменными ассетами;
|
||
* создать git-тег (semver) в GitHub-зеркале — HACS покажет версию.
|
||
|
||
## 3. Приёмка на живом стенде
|
||
|
||
* `tests/acceptance/test_esphome_ha.py quick` — матрица изменений (HA;
|
||
с `--esphome-host` шаги «режим/уставка» идут через ESPHome, проверка — по
|
||
состоянию в HA), возврат к исходному.
|
||
* `long --hours 24 --interval 3600 --report acceptance.csv` — суточный
|
||
прогон, отчёт дописывается по ходу.
|
||
* Сценарии: 503 (два слота заняты), key_error + Repair, offline и
|
||
восстановление, два устройства (разные порты прослушивания), options flow
|
||
(копирование/смена ключа), reconfigure без потери конверсий.
|
||
|
||
## 4. Ограничения текущего стенда
|
||
|
||
* Реального железа/облака в CI нет: протокол проверен mock-модулем
|
||
(`tests/ayla/mock_ac.py`), облако — мок-сервером; приёмочный скрипт имеет
|
||
self-test на моке HA REST.
|
||
* Суточный soak, re-key и облачный вход — только на приборе/аккаунте.
|
||
* ESPHome-канал приёмки требует установленного `aioesphomeapi` и
|
||
работающего ESPHome-компонента (PLAN_ESPHOME); без них скрипт работает
|
||
только со стороны HA.
|