fix(infra): ship alass and the translation backends #259

2026-08-26T09:40:15+01:00

naps62-yolo commented

2026-08-26 09:40:15 +01:00

Two parts of §15 were unreachable in the running image.

cargo build --release -p arr-daemon passed no --features, so all four
translation backends were compiled out and available_engines came back
empty. All four go in: which one is in use is a database setting, so the
build has no reason to choose.

alass was not installed at all. It is not in Debian, so a pinned release
binary comes from its own stage — the runtime image needs no download tool
and a source change does not refetch it.

Verified by building the image and running it:

$ docker run --rm --entrypoint sh arr-257:test -c 'alass --version'
alass-cli 2.0.0

$ curl -s localhost:17878/api/settings/subtitles | jq .available_engines
["openai","deepl","google","command"]

$ curl -s localhost:17878/api/health | jq '.subtitles.alass'
{"status":"ok"}

The arr binary is 19 MB with all four compiled in, inside §1's 20-40 MB
target. Health still reads degraded on TMDB key, opensubtitles credentials
and podnapisi — operator configuration, which the issue puts out of scope.

The asset is x86-64 only, which is what this image targets.

Closes #257

Two parts of §15 were unreachable in the running image. `cargo build --release -p arr-daemon` passed no `--features`, so all four translation backends were compiled out and `available_engines` came back empty. All four go in: which one is in use is a database setting, so the build has no reason to choose. `alass` was not installed at all. It is not in Debian, so a pinned release binary comes from its own stage — the runtime image needs no download tool and a source change does not refetch it. Verified by building the image and running it: <details> ``` $ docker run --rm --entrypoint sh arr-257:test -c 'alass --version' alass-cli 2.0.0 $ curl -s localhost:17878/api/settings/subtitles | jq .available_engines ["openai","deepl","google","command"] $ curl -s localhost:17878/api/health | jq '.subtitles.alass' {"status":"ok"} ``` The `arr` binary is 19 MB with all four compiled in, inside §1's 20-40 MB target. Health still reads `degraded` on TMDB key, opensubtitles credentials and podnapisi — operator configuration, which the issue puts out of scope. </details> The asset is x86-64 only, which is what this image targets. Closes #257

naps62-yolo added 1 commit 2026-08-26 09:40:15 +01:00

fix(infra): ship alass and the translation backends

ci / web (pull_request) Successful in 25s

Details

ci / rust (pull_request) Successful in 1m35s

Details

8c50e9ecb4

The release image built with no --features, so all four translation
backends were compiled out and §15's "translate when no provider has the
language" path could not run: /api/settings/subtitles answered with an
empty available_engines. All four go in — which one is in use is a
database setting, so the build has no reason to choose.

alass was missing outright, leaving health reporting 'alass not found at
alass' while §15 expects it over every fetched and every translated
subtitle. It is not in Debian, so a pinned release binary comes from its
own stage and the runtime image keeps needing no download tool.

Closes #257

naps62-yolo merged commit dfa4656509 into main

2026-08-26 09:51:09 +01:00

naps62-yolo deleted branch fix/257-image-ships-subtitles

2026-08-26 09:51:09 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: yolo/arr#259