Compare commits

..

2 Commits

Author SHA1 Message Date
alexbelgium
833d0d3758 docs(skill): narrow the ISO claim and correct the grep description
Review fixes. The bolded lead read as an absolute while the body reported 363
DD-MM-YYYY headings and told you to match the file — it now says "most", and
says outright that a DD-MM-YYYY file stays DD-MM-YYYY. The counts are stamped
as of 2026-08-25 so a future reader knows they are a snapshot.

CodeRabbit is right that `grep -q "^## ${version} ("` is not an exact-version
check. Reproduced: with version 5.1.1.2 the pattern matches a heading reading
`## 5X1Y1Z2 (`, because BRE dots match any character; `grep -qF` does not.
Described as an unescaped BRE instead. The conclusion is unchanged, since the
date is not in the pattern either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 15:53:31 +02:00
alexbelgium
138e7d7c33 docs(skill): correct the CHANGELOG heading date format
SKILL.md's step 7 said to match `## X.Y (DD-MM-YYYY)`. The repo does not use
that: 7705 dated CHANGELOG headings are ISO `YYYY-MM-DD` against 363 in
`DD-MM-YYYY`, and the newest entry is ISO in 125 of 135 add-ons. Following the
instruction cost a Copilot review round on #3019.

`DD-MM-YYYY` is not invented, which is presumably how it got written down. It
is what `onpush_builder.yaml` inserts with `date '+%d-%m-%Y'` when a push
arrives with no heading for the config.yaml version, and it is the addons_updater
bot's default in `99-run.sh` — but that bot runs here with `date_iso8601: true`
(confirmed against the running add-on's options), which is why almost everything
on master is ISO. Neither is a reason to write `DD-MM-YYYY` by hand.

The traps.md entry also records that the builder's duplicate check is
`grep -q "^## ${version} ("` — keyed on the exact config.yaml version and blind
to the date — so an ISO heading you wrote yourself still suppresses the bot's
insertion.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 15:48:00 +02:00
10 changed files with 17 additions and 45 deletions

View File

@@ -34,12 +34,6 @@ then generalising it to all hosts.**
would have deleted a user's hand-written configuration.
- A GPU probe created a hardware context — but that proved the driver worked, not that Chromium's
GPU path did.
- SABnzbd's source was grepped to see which proxy headers it reads, and `X-Forwarded-For` was
forwarded because it reads that one — but `verify_xff_header` is on by default and makes it
*reject* every address in the chain that is not local, so ingress answered 403 for anyone
reaching Home Assistant from outside the LAN (#3019, fixed in #3023). Every check ran from
inside the container, where no such header exists. **That an app reads a header is not a reason
to send it — find out what it does with it, and exercise the path a remote user takes.**
The pattern is always *inference standing in for detection*. Before changing a default, ask what
this is like on a host unlike yours. Prefer detecting the condition at runtime over asserting it.

View File

@@ -241,15 +241,17 @@ account. Note it and move on rather than guessing.
**Resolving a review thread requires GraphQL** (`resolveReviewThread`); the REST API cannot do it.
`scripts/pr_review.sh` wraps fetch / reply / resolve.
**CHANGELOG heading dates are ISO, whatever the bots' defaults say.** Match the format already in
the add-on's file. Repo-wide that is `## <version> (YYYY-MM-DD)`: 7705 dated headings against 363
in `DD-MM-YYYY`, and the newest entry is ISO in 125 of 135 add-ons. Copilot flags an ISO file that
gets a `DD-MM-YYYY` entry (#3019). `DD-MM-YYYY` is not invented — it is what `onpush_builder.yaml`
writes with `date '+%d-%m-%Y'` when it has to insert a heading you forgot, and what the
addons_updater bot writes when its `date_iso8601` option is off (`99-run.sh`; it is on in
production here) — but neither is a reason to write it yourself. The builder's duplicate check is
`grep -q "^## ${version} ("`, keyed on the exact `config.yaml` version and blind to the date, so
an ISO heading you wrote yourself still suppresses the bot's insertion.
**Most CHANGELOG heading dates are ISO, whatever the bots' defaults say.** Match the format
already in the add-on's file — a `DD-MM-YYYY` file stays `DD-MM-YYYY`. Where you have no
precedent, ISO is the house style: as of 2026-08-25, `## <version> (YYYY-MM-DD)` accounts for
7705 dated headings against 363 in `DD-MM-YYYY`, and the newest entry is ISO in 125 of 135
add-ons. Copilot flags an ISO file that gets a `DD-MM-YYYY` entry (#3019). `DD-MM-YYYY` is not
invented — it is what `onpush_builder.yaml` writes with `date '+%d-%m-%Y'` when it has to insert
a heading you forgot, and what the addons_updater bot writes when its `date_iso8601` option is
off (`99-run.sh`; it is on in production here) — but neither is a reason to write it yourself.
The builder's duplicate check is `grep -q "^## ${version} ("` — an unescaped BRE, so the dots in
a version match any character, and it does not look at the date at all. Either way an ISO heading
you wrote yourself still suppresses the bot's insertion.
**The repo's `.markdownlint.yaml` does not disable MD022/MD032**, so a CHANGELOG will show
dozens of pre-existing heading/list findings. They are noise because lint is `continue-on-error`,

View File

@@ -934,7 +934,6 @@ If you want to do add the repository manually, please follow the procedure highl
![Update](https://img.shields.io/badge/dynamic/json?label=Updated&query=%24.last_update&url=https%3A%2F%2Fraw.githubusercontent.com%2Falexbelgium%2Fhassio-addons%2Fmaster%2Fsabnzbd%2Fupdater.json)
![aarch64][aarch64-badge]
![amd64][amd64-badge]
![ingress][ingress-badge]
![smb][smb-badge]
![localdisks][localdisks-badge]

View File

@@ -1,9 +1,3 @@
## 20260828 (28-08-2026)
- Minor bugs fixed
## 20260826.1 (26-08-2026)
- Synced with upstream birdnet-go; new/updated PRs pending in fork
## 20260826 (26-08-2026)
- Minor bugs fixed
## 20260729.1 (2026-08-01)
- Version renamed from `source-20260729.1`, which Home Assistant could not order and therefore could not reliably offer as an update: every number of the previous version is kept, as a section of its own. The addon itself and the upstream version it tracks are unchanged

View File

@@ -127,5 +127,5 @@ slug: birdnet-go-dev
udev: true
url: https://github.com/alexbelgium/hassio-addons
usb: true
version: "20260828"
version: "20260729.1"
video: true

View File

@@ -1,11 +1,4 @@
## 20260826 (26-08-2026)
- Minor bugs fixed
## 20260716.1 (26-08-2026)
- Minor bugs fixed
## 20260716.1 (2026-08-26)
- Rebuild after syncing the alexbelgium/birdnet-go fork with upstream tphakala/birdnet-go and resolving conflicts on all open pull requests
## 20260716 (2026-07-16)
- Update to latest version from tphakala/birdnet-go (changelog : https://github.com/tphakala/birdnet-go/releases)

View File

@@ -128,4 +128,4 @@ slug: birdnet-go
udev: true
url: https://github.com/alexbelgium/hassio-addons/tree/master/birdnet-go
usb: true
version: "20260826"
version: "20260716"

View File

@@ -1,7 +1,4 @@
## 5.1.1.3 (2026-08-25)
- Fixed ingress returning `403 External internet access denied` when Home Assistant is reached from outside the local network. SABnzbd's `verify_xff_header` option, which is on by default, refuses any request whose `X-Forwarded-For` chain contains a non-local address, so the proxy no longer forwards that header.
## 5.1.1.2 (2026-08-25)
- Ingress is now enabled: the WebUI opens directly in the Home Assistant sidebar, and the "Open Web UI" button now goes there. Access by ip:port is unchanged, but has to be typed rather than clicked, as Home Assistant does not allow an add-on to offer both.
- Note for users who set a "Host verification" whitelist in SABnzbd: ingress sends `Host: 127.0.0.1:8080` upstream, because SABnzbd rejects any Host that is not an IP literal. That whitelist therefore no longer filters the ingress route, which is gated by Home Assistant authentication instead. Direct ip:port access is unchanged and still filtered.

View File

@@ -106,4 +106,4 @@ schema:
slug: sabnzbd
udev: true
url: https://github.com/alexbelgium/hassio-addons
version: "5.1.1.3"
version: "5.1.1.2"

View File

@@ -10,17 +10,10 @@ server {
# SABnzbd refuses any request whose Host is not an IP literal
# ("Access denied - Hostname verification failed"), so send the
# upstream socket rather than the browser's host.
# upstream socket rather than the browser's host. X-Forwarded-For is
# the only other header it reads (for its verify_xff_header option).
proxy_set_header Host $proxy_host;
# X-Forwarded-For must NOT be forwarded. verify_xff_header defaults to
# on, and check_access() then requires every address in the header to
# be local, so Supervisor's copy of the browser's public address makes
# SABnzbd answer 403 "External internet access denied" for anyone
# reaching Home Assistant from outside the LAN. Clearing it leaves
# SABnzbd looking at nginx's own loopback address. Access is gated by
# Home Assistant authentication before it ever reaches this proxy.
proxy_set_header X-Forwarded-For "";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# The interface itself only emits relative links, so no body
# rewriting is needed. Redirects are the exception: Raiser() emits