freesailarr: eight image updates, a trustedNetworks value for the arr apps, and one grouped Renovate PR from now on #121
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
d36112aaf6
|
chore(renovate): group the freesailarr stack into one PR per cycle
Validate Helm Charts / Detect changed charts (pull_request) Successful in 6s
Validate Helm Charts / Resource quantities (pull_request) Successful in 30s
Validate Helm Charts / Selector match (pull_request) Successful in 17s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 14s
Validate Helm Charts / Build freesailarr (pull_request) Successful in 7s
Validate Helm Charts / Trivy config freesailarr (pull_request) Successful in 24s
Install-test / Install-test freesailarr (pull_request) Successful in 4m9s
Validate Helm Charts / Install-test (pull_request) Successful in 4m9s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 12s
Publish Freesailarr Helm Chart / Publish Freesailarr Helm Chart (push) Successful in 12s
SonarQube Analysis / SonarQube Analysis (push) Successful in 50s
The first groupName in this config, and a deliberate reversal for one chart of the stance the file records above its app-version managers: that the helm-values manager finds freesailarr's ten images and proposes one update per image. That described what Renovate does, not what the chart wants. For every other chart here one PR per image is already one PR per chart. What it fixes, measured against the Gitea API on 2026-10-12: eight of the ten images had an open PR at the same moment (#102, #103, #104, #105, #106, #107, #108, #111). Each edits freesailarr/values.yaml and, through the postUpgradeTasks hook, freesailarr/Chart.yaml - so the API reported mergeable: false for all eight, since they rewrite the same version: line. One can merge; the other seven then need a rebase each, and every rebase restarts the most expensive install-test in this repo. The second symptom is sharper: all eight carried version: 3.1.1+up1.0.0 -> 3.1.2+up1.0.0 while main already stood at 3.3.0+up1.0.0, because the hook derives everything from the base commit and those branches predated the Gateway-API rounds. A rebase repairs it, which is the point - nothing fails if the rebase does not happen first. Two rules rather than one, and not for tidiness: renovate rejects the combination outright with "packageRules cannot combine both matchUpdateTypes and separateMinorPatch", a config-validation error. That is consistent, since separateMinorPatch decides the split a rule would then be selecting on. Without the second rule the group still arrives as two PRs - verified by dry-run against a checkout holding those eight updates, they split onto renovate/freesailarr-stack (the three minors) and renovate/patch-freesailarr-stack (the five patches); note that the setting prefixes the branch rather than suffixing it. With both rules, one branch carries all eight. Decisions, with their reasons in the rules themselves: matched by file name so that no second list of image names has to be kept current (an image added later would silently never join the group); mediathekarr included, since its digest PR blocks the others identically - checked with a stale digest, because a current pin makes a working and a broken rule look the same; gluetun and busybox included, as neither's role has anything to do with the blocking; and majors kept out via matchUpdateTypes, so the stepwise app-major procedure and separateMultipleMajor keep working. What it cannot show from here: Renovate runs as the shared instance outside this repository, so the evidence available is a config that validates and a local lookup that groups as intended - not the next real run. |
||
|
|
7003f3674c
|
feat(freesailarr)!: eight image updates and a trustedNetworks value for the *arr apps
Collapses the eight open Renovate PRs for this stack into one change, and answers what two of them turned out to carry. The eight tags: qbittorrent 5.2.3 -> 5.2.4, bazarr 1.6.0 -> 1.6.2, sonarr 4.0.19 -> 4.0.20, flaresolverr v3.5.0 -> v3.5.2, recyclarr 8.7.1 -> 8.7.3, prowlarr 2.5.2 -> 2.6.5, radarr 6.3.0 -> 6.4.4, seerr v3.4.1 -> v3.5.0. gluetun, the busybox init image and the digest-pinned mediathekarr have no update pending and are untouched. Major rather than patch, because prowlarr 2.6.3 and radarr 6.4.3 are not plain bumps: they removed the hard-coded trusted proxy networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7, fe80::/10, read in Startup.cs at the previously pinned tags) and replaced them with a TrustedNetworks setting whose own default is string.Empty - ForwardedHeadersConfigurator returns before registering a single KnownNetwork while it is empty. Behind an in-cluster ingress controller that means the forwarded headers are ignored: the client address the app reports is the controller's pod IP, the scheme reads as http behind TLS termination, and under "Disabled for Local Addresses" a proxied request stops counting as local. So a <app>.trustedNetworks value is added for prowlarr, radarr AND sonarr, rendered as <APP>__SERVER__TRUSTEDNETWORKS and only when non-empty - an empty variable cannot be told apart from an unset one by the app, but looks handled to a reader of the manifest. The env form was verified per app rather than inferred: all three bind ServerOptions to <App>:Server next to a plain AddEnvironmentVariables(). A helper suppresses the chart's entry when the app's own env block already carries the variable, for the reason the UrlBase helper states - two identically named variables in one container are not a defined state. sonarr is included because it is already in the empty state: 4.0.19, the version this chart shipped before, has no hard-coded networks either. It arrived in what the convention classes as a plain app-version bump, so nothing reviewed or documented it. Repairing two and knowingly leaving the third would be the same silent pattern. The default is empty, and this therefore does NOT restore the behaviour from before the upgrade. That is deliberate and follows upstream's reason - trusting X-Forwarded-For from any private network is a spoofing vector - and it is made visible instead of reinstated: NOTES.txt warns in exactly the combination that costs something, the app published through an Ingress or an HTTPRoute and the value empty, and stays quiet otherwise. AllowedHosts, added by the same upstream releases, is deliberately not exposed. Its default is string.Empty as well and the app then accepts any host, so there is nothing to repair; the trap is documented instead, because if it is ever set the app appends only localhost, 127.0.0.1, [::1] and its own hostname - neither the pod IP nor the Service DNS name - and the kubelet probes the pod by IP, which an incomplete list answers with HTTP 400. At default values the rendered manifest changes in exactly eight lines, the image tags; the new value renders nothing until it is set. |