mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-10-05 16:01:34 +02:00
Compare commits
5 Commits
bb6dee8f91
...
revert/fbq
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
bae169871a | ||
|
|
979f7dbe5c | ||
|
|
1d86e79dce | ||
|
|
331af4bcc9 | ||
|
|
141ffe9075 |
@@ -58,3 +58,60 @@ Once the rebuilt add-on is running, re-run the measurement that motivated the wo
|
||||
cannot be self-verified — a service that reads its environment only at start makes an env-var fix
|
||||
unproven until the add-on restarts, which needs the user or `ha-cli` with their agreement. If you
|
||||
cannot restart, the change is **Assumed**, not Verified, and must be reported that way.
|
||||
|
||||
## A local reproduction that passes does not outrank a user's production report
|
||||
|
||||
PR #3026 added an nginx `sub_filter` to the `filebrowser_quantum` ingress vhost. After it merged,
|
||||
the user reported that Download had stopped working — the file opened inline instead. Every check
|
||||
run against the change came back clean:
|
||||
|
||||
- the shipped bundle's Download action builds an `<a href>` and clicks it, and never calls
|
||||
`window.open`, which is all the injected shim overrides;
|
||||
- the shim's own predicate, evaluated live in the running app, returned false for the download
|
||||
URL, the `inline=true` raw URL and the public-share download URL;
|
||||
- the download response through the vhost was **byte-identical** with and without the `sub_filter`
|
||||
(`Content-Disposition: attachment` intact, `Content-Length` unchanged), for `text/plain` and for
|
||||
the `text/html` case the filter actually scans;
|
||||
- upstream's frontend download code is unchanged from v1.5.0-stable to v1.5.4-stable, and Home
|
||||
Assistant's ingress iframe carries no `sandbox` attribute (`ha-panel-app.ts`), so downloads are
|
||||
not sandbox-blocked either.
|
||||
|
||||
None of that reproduced the failure, and none of it explained the one fact that mattered: the user
|
||||
saw it fail under ingress and work on the add-on's direct port, and the `sub_filter` was the only
|
||||
ingress-side change in that update. **Revert first and keep investigating.**
|
||||
|
||||
A revert can also discriminate — if the symptom survives it, the cause was the concurrent upstream
|
||||
bump rather than the diff — but only if **both builds resolve the same upstream image**. With
|
||||
`build_from: <image>:latest` they need not: `latest` can move between the two rebuilds, and then
|
||||
the comparison proves nothing. Resolve the tag to a digest and record it before and after, or pin
|
||||
`build_from` to that digest for the duration of the experiment:
|
||||
|
||||
```bash
|
||||
T=$(curl -s "https://auth.docker.io/token?service=registry.docker.io&scope=repository:<repo>:pull" | jq -r .token)
|
||||
curl -s -H "Authorization: Bearer $T" \
|
||||
-H "Accept: application/vnd.oci.image.index.v1+json" \
|
||||
"https://registry-1.docker.io/v2/<repo>/manifests/latest" \
|
||||
| jq -r '.manifests[] | select(.platform.architecture=="amd64" and .platform.os=="linux") | .digest'
|
||||
```
|
||||
|
||||
For the case above both builds resolved `gtstef/filebrowser:latest` amd64 to
|
||||
`sha256:e549e1a9b5de573c276f7be67444841559e3f89cbc664a2f926968453d069436` (v1.5.4-stable, created
|
||||
2026-08-29T14:19:56Z), so that comparison was controlled — but it was luck, not design.
|
||||
|
||||
Worth building next time, because it took most of the session and is reusable: a reproduction rig
|
||||
made **out of the published image's own layers**, with no dockerd. Pull the manifest and blobs from
|
||||
the registry with `curl` + `jq`, untar them in order, then run the extracted binary through the
|
||||
image's own musl loader (`root/lib/ld-musl-x86_64.so.1 ./filebrowser`) with the real `http/dist`
|
||||
next to it. Plain `tar` does not interpret whiteouts, so a file a later layer deletes
|
||||
(`.wh.<name>`) or a directory it marks opaque (`.wh..wh..opq`) survives into the reconstructed
|
||||
rootfs; check with `tar tzf <layer> | grep '\.wh\.'` and reach for an OCI-aware unpacker if any
|
||||
turn up. (There were none in `gtstef/filebrowser:latest` — all eleven layers, 0 whiteout entries —
|
||||
so that rig was faithful.) Put the add-on's rendered `ingress.conf` in front of it, and a second nginx server in
|
||||
front of that to strip the `/api/hassio_ingress/<token>` prefix the way Supervisor does. That gets
|
||||
the real frontend, the real backend and the real vhost under a browser — everything except
|
||||
Supervisor itself.
|
||||
|
||||
**`build_from: <image>:latest` means every merge ships an upstream version bump too.** Record which
|
||||
upstream version each add-on image was built from — the registry config blob's `created` timestamp,
|
||||
the resolved manifest digest, and the binary's version string — before attributing a regression to
|
||||
the diff.
|
||||
|
||||
13
.github/stargazer_countries.csv
vendored
13
.github/stargazer_countries.csv
vendored
@@ -273,6 +273,7 @@ Gajalshankar,India,
|
||||
Gangol,,2026-08-10
|
||||
Garak1980,,2026-08-10
|
||||
GaryOG,,2026-08-10
|
||||
GentryChe,,2026-08-30
|
||||
Germaenace,,2026-08-10
|
||||
Getrio,Italy,
|
||||
Ghost-Sam1222,,2026-08-10
|
||||
@@ -385,6 +386,7 @@ JosephBlock,United States,
|
||||
Julian1701,,2026-08-10
|
||||
JulienFloris,Netherlands,
|
||||
JuraLadanov,,2026-08-10
|
||||
Jutsch,,2026-08-30
|
||||
K0stIa,,2026-08-10
|
||||
KRC604,,2026-08-10
|
||||
KairuByte,,2026-08-10
|
||||
@@ -441,6 +443,7 @@ Lizzardis,,2026-08-10
|
||||
LoginByCall,,2026-08-10
|
||||
Lolekpolek,,2026-08-10
|
||||
LonelySoul7X,,2026-08-10
|
||||
Loong-He,China,2026-08-30
|
||||
Lorsel,Italy,
|
||||
Luca2165801154,,2026-08-10
|
||||
Lucius-Waverly,,2026-08-16
|
||||
@@ -990,6 +993,7 @@ berkovich98,,2026-08-10
|
||||
bertrand-f,,2026-08-10
|
||||
bes-r,Netherlands,
|
||||
bestnub,Germany,
|
||||
betechyou,,2026-08-30
|
||||
beyercenter,,2026-08-10
|
||||
bezigebever,,2026-08-10
|
||||
bggsolar,Germany,
|
||||
@@ -1225,6 +1229,7 @@ denisgolius,Ukraine,
|
||||
dennisjonda,Germany,
|
||||
dennisvandalen,Netherlands,
|
||||
denvernbd,Russian Federation,2026-08-10
|
||||
der-berni,Germany,2026-08-30
|
||||
derailius,,2026-08-10
|
||||
dethpickle,United States,
|
||||
dev4jam,Australia,
|
||||
@@ -1522,6 +1527,7 @@ hreikin,United Kingdom,
|
||||
hsiguy,,2026-08-10
|
||||
huangyixinv,,2026-08-10
|
||||
hubikj,,2026-08-10
|
||||
hufforguk,,2026-08-30
|
||||
hugobloem,United Kingdom,
|
||||
hujiayi0126,,2026-08-10
|
||||
hunterlong,United States,
|
||||
@@ -1661,6 +1667,7 @@ joshcliffejones,United Kingdom,
|
||||
joshmeads,Canada,
|
||||
josiah-eichelman,,2026-08-10
|
||||
jpaulomt,,
|
||||
jpeisach,United States,2026-08-30
|
||||
jpmaldonado,,2026-08-10
|
||||
jpoll962,,2026-08-10
|
||||
jpombas,Portugal,
|
||||
@@ -1831,6 +1838,7 @@ mProwler,United States,
|
||||
mStrangers,,2026-08-10
|
||||
mabt,,2026-08-10
|
||||
macedobernardo,,2026-08-10
|
||||
machineGnu,,2026-08-30
|
||||
madjetey,,2026-08-10
|
||||
maggle-swim,,2026-08-10
|
||||
malachitgruen,Germany,
|
||||
@@ -1840,6 +1848,7 @@ manu7691,United States,
|
||||
manugratx,,2026-08-10
|
||||
mapeje,Sweden,
|
||||
maphouse,Canada,
|
||||
marat-365,,2026-08-30
|
||||
maratbakirov,,2026-08-10
|
||||
marcetad,,2026-08-10
|
||||
marcjay,United Kingdom,
|
||||
@@ -1849,6 +1858,7 @@ marcschraepler,Austria,
|
||||
marcusrbrown,,2026-08-10
|
||||
mareklab,,2026-08-10
|
||||
marevers,Germany,
|
||||
marialaranjo,,2026-08-30
|
||||
marian-paun,Romania,
|
||||
mariusvslprts,Germany,
|
||||
mark-219,United States,2026-08-16
|
||||
@@ -2173,6 +2183,7 @@ pwitte,,2026-08-10
|
||||
pxshh,,2026-08-10
|
||||
pynbbz,,2026-08-10
|
||||
pyrech,France,
|
||||
pysj,,2026-08-30
|
||||
pziezio,Poland,
|
||||
pzkpfw6,,2026-08-10
|
||||
qadk,,2026-08-10
|
||||
@@ -2196,6 +2207,7 @@ rascasseuk,,2026-08-10
|
||||
raul811,,2026-08-10
|
||||
raulpetruta,Romania,
|
||||
rawpie2,,2026-08-10
|
||||
raymand211092,Cuba,2026-08-30
|
||||
raytedjaja,,2026-08-10
|
||||
rbalaev,,2026-08-10
|
||||
rbaron,,2026-08-10
|
||||
@@ -2211,6 +2223,7 @@ reggiano,,2026-08-10
|
||||
reid,United States,
|
||||
reinvanhaaren,Netherlands,
|
||||
remb0,Netherlands,
|
||||
renatoptr,,2026-08-30
|
||||
renejr63,,2026-08-10
|
||||
resomi,,2026-08-10
|
||||
retpolanne,Brazil,
|
||||
|
||||
|
BIN
.github/stargazer_map.png
vendored
BIN
.github/stargazer_map.png
vendored
Binary file not shown.
|
Before Width: | Height: | Size: 68 KiB After Width: | Height: | Size: 404 KiB |
@@ -1,4 +1,20 @@
|
||||
|
||||
## 1.5.3.2 (2026-08-30)
|
||||
- Revert the 1.5.3.1 ingress filter while a report of broken downloads is
|
||||
investigated. "Open parent directory" in the tool views opens a new tab
|
||||
again, as it did up to 1.5.3.
|
||||
|
||||
## 1.5.3.1 (2026-08-29)
|
||||
- Fix "open parent directory" in Tools -> File Size Analyzer under Home
|
||||
Assistant ingress. FileBrowser opened the parent folder in a new tab, which
|
||||
lands on the raw ingress URL with no Home Assistant frontend around it to
|
||||
keep the ingress session alive, so the new tab answered 401 instead of
|
||||
showing the folder. The ingress vhost now turns that popup into a navigation
|
||||
of the panel itself. The same fix covers the other tool views and the "go to
|
||||
item" action on search results, which open a new tab the same way. Download
|
||||
and preview popups, links pointing out of the add-on, and direct access on
|
||||
port 8071 are unchanged.
|
||||
|
||||
## 1.5.3 (2026-08-29)
|
||||
- Update to latest version from gtsteffaniak/filebrowser (changelog : https://github.com/gtsteffaniak/filebrowser/releases)
|
||||
|
||||
|
||||
@@ -118,4 +118,4 @@ schema:
|
||||
slug: filebrowser_quantum
|
||||
udev: true
|
||||
url: https://github.com/alexbelgium/hassio-addons
|
||||
version: "1.5.3"
|
||||
version: "1.5.3.2"
|
||||
|
||||
Reference in New Issue
Block a user