- 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
4.9 KiB
4.9 KiB
Чек-лист релиза 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):
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.