test: Fix the weekly run against current Home Assistant - #23
Merged
Merged
Conversation
The weekly `latest HA` run has been red since 2026-08-31. Five tests called device_registry.async_get_device, which now raises rather than warns and is removed in 2027.8.0. No production code was affected: api.py already looks our device row up with async_entries_for_config_entry, and explains why. The tests were the only callers, so users saw nothing. What it cost was the canary itself, a job whose only value is being red exactly when something upstream breaks. async_get_device_by_identifier takes the config entry id, so the tests now scope the lookup the same way production does rather than resolving an identifier we deliberately share with the official integration. Verified against 2026.9.0b4: 5 failed before, 232 pass after.
A scheduled run failing notifies nobody: there is no pull request to redden and no pushing author to mail. That is how `latest HA` stayed red for two days without anyone noticing, which is the entire value of the job gone. One open issue at a time, commented on rather than reopened weekly. An upstream break stays broken until someone fixes it, so a fresh issue every Monday would bury the original under its own duplicates. Not wired to `workflow_dispatch`: a manual run already has someone watching it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The weekly
latest HArun has been red since 2026-08-31. Fixes the break and makes the next one notify someone.1. The break
Five tests called
device_registry.async_get_device, which current Home Assistant raises on rather than warns about, and removes in 2027.8.0.No production code was affected.
api.pyalready resolves our device row withasync_entries_for_config_entryand documents why. The tests were the only callers, so users saw nothing. What it cost was the canary: a job whose only value is being red exactly when something upstream breaks.async_get_device_by_identifiertakes the config entry id, so the tests now scope the lookup the way production does instead of resolving an identifier we deliberately share with the official integration.2. Nobody was told
A scheduled failure has no pull request to redden and no pushing author to mail, which is how this sat for two days. A new job files an issue instead, on
scheduleonly, since a manual run already has someone watching it.One open issue at a time, commented on rather than reopened weekly, so a break that stays broken does not bury the original under duplicates. Both paths were run with
ghstubbed. Job-levelpermissionsrestatescontents: readbecause job permissions replace the workflow's rather than adding to them.Testing
Installed current Home Assistant (2026.9.0b4) in a scratch venv and ran the suite, since
latest HAdeliberately never runs on a pull request and this PR's CI therefore cannot prove the fix:The 5 match the CI failures exactly. Worth a
workflow_dispatchofValidateonmainafter merge to confirm on the runner.