jschoubben
e1febc053f
lidarr reached its download clients as nzbget:6789 and qbittorrent:8112 and its indexers through jackett:9117 or indexers.zurag.be - HAL container names and a public route, typed into its database by hand. Nothing on the mesh answers those names. It now requires nzbget-api, qbittorrent-api and jackett-api. A run-once step (downloads/, declared last, restart-on its bindings, credentials and settings) writes host, port, TLS, base path, user and credential into lidarr through lidarr's own API: - A download client is the mesh's when its name is downloads.<provision>.name and its kind the provider's; it is registered when missing. A jackett feed is the mesh's when its host is the bound one, one the step bound before, or one in downloads.jackett-api.adopt-hosts; the jackett indexers in downloads.jackett-api.indexers are registered when missing. Every other entry is left alone, and nothing is ever deleted. - Only connection fields, only when they differ. The stored password is masked, so the app tests the entry with the credential it holds; only if that fails is the delivered one written. Categories, priorities and "enabled" are never touched. - Each credential is tried against its provider first. A minted value (nothing accepted yet) is never written; the step exits 1 naming the exact secret accept. The step is byte-identical in sonarr, radarr, lidarr and bookshelf (the same Servarr API, v3 or v1): each module builds from its own directory, so each carries a copy, and test/downloads.test.ts fails if a sibling's copy differs. Verified: strict typecheck, the Dockerfile build, 14 unit tests; and the compiled step against fresh pinned sonarr/radarr/lidarr/bookshelf with throwaway nzbget, qBittorrent and jackett - minted credentials refused with nothing written, accepted ones registered and tested by the app, a migration-shaped radarr repointed, reruns unchanged.
28 lines
1.5 KiB
Docker
28 lines
1.5 KiB
Docker
# lidarr's runtime: the tool runtime, carrying this module's compiled code.
|
|
#
|
|
# **Built from this module's own directory and nothing else.** The sdk and the tool runtime are in
|
|
# the base images, published like any other artifact — which is what makes this buildable by the
|
|
# mesh from a repository and a path (novox/hq ADR 0069) rather than only on a workstation that
|
|
# happens to have the siblings.
|
|
#
|
|
# Two bases, named rather than pinned (novox/hq issue 044): the image this is COMPILED in and the
|
|
# image it RUNS in — the second must not carry a compiler. Declared in module.json's `build.on`.
|
|
ARG BUILD_BASE
|
|
ARG RUNTIME_BASE
|
|
|
|
FROM ${BUILD_BASE} AS build
|
|
WORKDIR /app/modules/lidarr
|
|
COPY . .
|
|
RUN node /app/node_modules/typescript/bin/tsc client.ts index.ts tools/index.ts downloads/settings.ts downloads/index.ts \
|
|
--module NodeNext --moduleResolution NodeNext --target ES2022 --outDir dist
|
|
|
|
FROM ${RUNTIME_BASE}
|
|
COPY --from=build /app/modules/lidarr/dist /app/modules/lidarr/dist
|
|
# Every serve-time entrypoint, loaded by the runtime in serve mode: tools and events serve, and a
|
|
# provider's provisioner runs its reconcile loop in the same process, with the broker connected —
|
|
# the convention novox/hq issues 060/061 settled.
|
|
ENV MESH_TOOL_MODULES=/app/modules/lidarr/dist/index.js,/app/modules/lidarr/dist/tools/index.js
|
|
# NOT dist/downloads/index.js: that is a step the host runs to completion, named by the `downloads`
|
|
# container's args as `mesh-tools run …` (novox/hq ADR 0052). Listed here it would run inside the
|
|
# serving sidecar too, and exit it.
|