This repo has no tags and no GitHub releases, and manifest.json has read
"1.0.0" since the integration was vendored -- unchanged across 20 commits,
including today's breaking reshape of the config flow. HACS falls back to
serving the default branch when there are no releases, so every download is
indistinguishable from the last and there is no way to tell what is running.
- scripts/release.py bumps manifest.json, commits and creates an annotated
tag in one step. It refuses a dirty tree, a branch other than main, a main
that differs from origin/main, a malformed version and an existing tag. It
stops short of pushing, since pushing the tag is what publishes.
- .github/workflows/release.yaml triggers on v* tags and refuses to publish
when the tag and manifest.json disagree. That mismatch is the failure worth
guarding: HACS offers the tag while Home Assistant reports the manifest, so
you install "v0.2.0" and the integration page says 0.1.0. It then creates
the release with gh (no third-party action).
- tests/test_version.py keeps the manifest version parseable by
AwesomeVersion (what HACS validates with) and in the shape the release
script accepts, so a release never fails on the version string itself.
Scheme: 0.x while the config entry shape is still in motion -- it changed
twice today -- and 1.0.0 when it settles. Documented in the README.
Local: 169 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NxJYWgGJtCw13qUHZtG8ki
Every label, description and error in this integration's UI renders
untranslated in a live Home Assistant. homeassistant.helpers.translation
loads `<integration>/translations/<lang>.json` and nothing else (there is
no fallback to strings.json -- see translation.py's
`integration.file_path / "translations" / file_name`), and this component
has no translations/ directory at all.
Core integrations get away with shipping only strings.json because core
generates translations/ as a release step, resolving the `[%key:...%]`
references strings.json uses to avoid duplicating text. Vendoring the
source tree copies the input and leaves out the generated output, so the
defect arrived with commit 48195c9 and would hit anyone who installs
this from HACS.
Rather than hand-write the file once and let it rot on the next upstream
re-sync, scripts/generate_translations.py regenerates it:
- `common::...` references resolve against the *installed* homeassistant
package's own strings.json, so the text matches what core would have
produced for that HA version.
- `component::openai_compatible::...` self-references resolve against
strings.json itself, repeatedly, since a reference can point at another
reference.
- Anything it cannot resolve (an unknown namespace, a reference to a
different integration, a path that does not exist, a marker surviving
the final pass) is a hard error rather than a raw `[%key:...%]` marker
shipped into a label.
All 70 references in strings.json resolve; the generated file carries
config, config_subentries, exceptions, issues, selector and services.
tests/test_translations.py locks it down: en.json must exist, must equal
what the generator produces, and must contain no surviving markers.
Verified the check actually catches drift rather than passing vacuously
-- perturbing one label fails it, and deleting the file fails it.
Local: 141 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NxJYWgGJtCw13qUHZtG8ki
