* fix(fileflows): install .NET 10 ASP.NET Core Runtime to match current release
FileFlows now ships its server/node binaries targeting .NET 10
(Microsoft.NETCore.App 10.0.0), but the install script still installs the
ASP.NET Core Runtime 8.0. On a fresh install the app therefore cannot start:
You must install or update .NET to run this application.
Framework: 'Microsoft.NETCore.App', version '10.0.0' (x64)
The following frameworks were found:
8.0.28 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
so "dotnet FileFlows.Server.dll --systemd install" fails with exit code 150
(service failed to start) and the container aborts (issue #15686).
Bump the runtime to 10.0 on both branches: aspnetcore-runtime-10.0 from
packages.microsoft.com on amd64 (the same repo and package already used by
igotify, rdtclient and technitiumdns) and dotnet-install --channel 10.0 on
arm64.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(fileflows): ensure current .NET runtime on update too
An existing install set up under an older .NET (e.g. aspnetcore-runtime-8.0)
would download a newer FileFlows on update but keep the old runtime, failing to
start with the same framework-not-found error. Mirror the runtime handling used
by technitiumdns/rdtclient in update_script.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
AdventureLog's frontend install runs a bare `pnpm i`. On pnpm v10+, build
scripts of dependencies (esbuild, es5-ext, svelte-preprocess) are ignored by
default and pnpm aborts with ERR_PNPM_IGNORED_BUILDS (exit 1), so the install
never reaches `pnpm build`. The shipped frontend/pnpm-workspace.yaml already
pins esbuild, so those builds are expected to run.
Enable the builds for this app only by appending `dangerouslyAllowAllBuilds:
true` to the frontend's pnpm-workspace.yaml before `pnpm i`, in both the install
and update paths. The change is guarded so it is not duplicated on re-run, and
it is scoped to AdventureLog (which ships no onlyBuiltDependencies) to avoid the
global config conflict that a repo-wide setting would cause.
Fixes#15670
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
When the optional Unbound install is chosen with DoT forwarding, the script
truncated (>) /etc/unbound/unbound.conf.d/pi-hole.conf and rewrote it starting
with an indented "tls-cert-bundle:" option that has no "server:" section header.
unbound-checkconf rejects this ("syntax error, is there no section start"), so
"systemctl restart unbound" exits 1 and the install aborts (line 153). The
overwrite also dropped the interface/port 5335 settings Pi-hole forwards to.
Append (>>) the DoT additions to the existing recursive server block instead,
under a proper "server:" section (unbound merges multiple server: clauses), so
the tls-cert-bundle and forward-zone are valid and the resolver keeps listening
on 127.0.0.1:5335. Recursive (non-DoT) mode is unchanged.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Ensure cleanup runs from `/opt/babybuddy` before deleting old files, add `--` to the removal command for safer argument handling, and run `manage.py makemigrations` before `migrate` so database updates are applied reliably during upgrades.
The completion message previously pointed to the bare host:port,
which serves the proxy API rather than the admin UI. Provider
authentication happens at /management.html.
Co-authored-by: root <root@paperclip.pilz.dev>
Replace the destructive multi-select container update block with a
proper per-container Y/N workflow:
- Unattended / non-interactive (DOCKER_NONINTERACTIVE=1 or no tty):
skip silently -- no docker pulls, no prompts.
- Interactive: stop_spinner() before any prompt to keep the terminal
clean, then for each container with a newer image:
Compose-managed → prompt Y/N (auto-no after 60 s)
→ on Y: docker compose pull <service> &&
docker compose up -d <service>
Standalone run → prompt Y/N (auto-no after 60 s)
→ on Y: docker pull only; no stop/rm;
user is told to recreate manually
- portainer / portainer_agent are excluded (handled earlier in
setup_docker)
The old code always stopped and removed the container without
recreating it, leaving users with a destroyed service. Standalone
containers without a Compose project can never be auto-recreated
safely, so only the image is pulled.
Fixes#15601
community-scripts-pr-app[bot]