The default path set USE_CLOUD_INIT itself, so the username and
password dialogs were skipped; only the advanced path asked. The cloud
image sets no password, so the question is which credentials, not
whether. Same fix as almalinux-vm and fedora-vm.
* suggestarr: keep the data where the app actually reads it
The env file sets CONFIG_DIR=/opt/suggestarr_data and the service passes
it through, but SuggestArr never reads that variable. Its database
manager builds the path from the application directory:
DB_PATH = os.path.join(BASE_DIR, 'config', 'config_files', 'requests.db')
so config.yaml, requests.db and secret.key live under /opt/suggestarr,
which the update wipes with CLEAN_INSTALL. Every update came back as a
fresh install.
Make config/config_files a symlink to /opt/suggestarr_data and lay it
down again after each deploy, since the deploy replaces it with a real
directory. Existing installs have their files copied across first, with
cp -an so anything already in the data directory wins.
CONFIG_DIR stays in the env file: it is inert today and costs nothing if
upstream starts reading it.
* suggestarr: let a failed migration stop the update
The || true was wrong and the review caught it. CLEAN_INSTALL wipes
/opt/suggestarr right after this copy, so swallowing a failure here
means the source is deleted with nothing carried across.
The guard was not even doing anything: cp -an exits 0 when it skips a
file that already exists in the target, which is the only case that
looked like it needed one. It only returns non-zero on a real failure,
which is exactly when the update has to stop - and it now stops before
the deploy, with the original data still in place.
cp -an, target file exists -> exit 0, continues
cp -an, source missing -> exit 1, ERR trap, aborts before deploy
2>/dev/null goes as well, so the reason is visible.
* refactor: streamline OxiCloud installation process by using prebuilt binaries
* oxicloud: take the prebuilt binary in the update too
Upstream now attaches musl tarballs to every release (AtalayaLabs/
OxiCloud#533), so the update no longer has to install a Rust toolchain
and Node and compile for up to 35 minutes. That compile is also what
broke #16216: a release whose source did not build left users with a
failed install and no way forward.
The tarball carries one top-level directory, which the deploy helper
strips, so the binary lands at /opt/oxicloud/oxicloud. The frontend is
baked into it, so the SPA build and OXICLOUD_STATIC_PATH both go; the
variable is commented out rather than removed, since a stale ./static
path would otherwise point at a directory that no longer exists.
migrate-nfc-filenames is gone as a separate binary - it is now a
subcommand, oxicloud migrate nfc-filenames - so the update removes the
old one. ffmpeg replaces build-essential: the server forks it for video
thumbnails and it is the one runtime dependency the musl build still
needs from the system.
Defaults drop to 2 CPU and 2048 MB, which were sized for the compile.
* oxicloud: install ffmpeg on update as well
The install gained it, the update did not, so a container created before
this change would never get it. The musl binary forks ffmpeg for video
thumbnails; without it that one feature stays silently unavailable.
* immichframe: set the admin password the new admin UI requires
immichFrame/ImmichFrame#698 added an admin UI that refuses to open
/admin unless IMMICHFRAME_ADMIN_PASSWORD is set, leaving users to edit
the unit by hand after an install or an upgrade from an older version.
Generate one, put it in the unit next to the other Environment lines,
and record it in ~/immichframe.creds the way the other scripts record
credentials. The update adds the line only when it is missing, so a
password already set by hand survives.
* immichframe: write the creds file the way the other scripts do
Sixty install scripts use cat <<EOF for their .creds file and exactly
one used an echo block, which was this one. Match the rest.
The install writes the file, the update appends: on an existing
container the file may already be there from the original install, and
the password line is only added when the unit has none.
Upstream derives everything from one setting:
ROMM_BASE_PATH = _get_env("ROMM_BASE_PATH", "/romm")
LIBRARY_BASE_PATH = f"{ROMM_BASE_PATH}/library"
There is no separate library setting; config.yml's roms_folder is only
a folder name inside the library. So ROMM_BASE_PATH in /opt/romm/.env
is the single lever, and everything that names a path has to follow it.
Two places did not. The watcher unit had /var/lib/romm/library written
into ExecStart, so a moved library was still watched at the default and
rescans never fired. It now uses ${ROMM_BASE_PATH}/library, which
systemd expands from the EnvironmentFile the unit already loads.
The Angie alias was derived from the env file, but only while the
install or an update ran. Editing ROMM_BASE_PATH afterwards left the
internal /library/ location pointing at the old path, and since the
backend serves content through X-Accel-Redirect, every download and
every play returned 404 while scanning and metadata kept working.
Re-sync it from an ExecStartPre on angie, so a restart is enough.
Update installs both for existing containers and rewrites the watcher
unit in place.
Reported in #17263. The suggested fix there was to template the alias,
which the scripts already did; the gap was that nothing re-applied it.
* Add allstarlink-vm (vm)
* Add MickLesk as co-author in allstarlink-vm.sh
Updated author information to include MickLesk.
---------
Co-authored-by: push-app-to-main[bot] <203845782+push-app-to-main[bot]@users.noreply.github.com>
Co-authored-by: CanbiZ (MickLesk) <47820557+MickLesk@users.noreply.github.com>
* sparkyfitness: run the Better Auth migration during the update
1.7.1 ships a Better Auth version whose schema has columns 1.6.5 never
created, and nothing in the update adds them. The backend starts, then
refuses every sign-in:
Database schema mismatch
Missing columns session.impersonated_by two_factor.verified ...
Run `npx auth migrate` to add the missing tables and columns.
Run exactly that after the backend dependencies are in place, with the
config Better Auth looks for, SparkyFitnessServer/auth.ts, and the
database credentials from /etc/sparkyfitness/.env. Users who hit this
were left running the server by hand to get the columns created.
A failure warns instead of aborting: the rest of the update has already
succeeded at that point, and the message names the remaining step.
* sparkyfitness: start the server through the entrypoint that migrates
The Better Auth CLI added in the previous commit is the wrong tool. It
generates sso_provider.user_id as text and cannot reference this
schema's uuid user.id:
foreign key constraint "sso_provider_user_id_fkey" cannot be
implemented [...] incompatible types: text and uuid
The real cause is one line up in the unit. It ran
tsx SparkyFitnessServer.js
which imports the application module directly and never applies the
schema migrations. Upstream starts through index.ts - nodemon.json has
exec: tsx index.ts - and that file runs applyMigrations() and
applyRlsPolicies() before importing anything, with a comment naming this
exact failure:
Better Auth validates the database schema eagerly, the moment
betterAuth() is constructed at auth.ts module scope [...] When
migrations ran later (from inside SparkyFitnessServer.ts) that check
read the pre-migration schema on the first boot after an upgrade, so
every /api/auth request failed until the container was restarted.
Point both the install and the update at index.ts and drop the CLI call.
index.ts exits non-zero when a migration fails, so systemd surfaces that
instead of serving a broken login.
6.87.0 moved init.sh from the repository root to docker/init.sh, so the
update stopped at
chmod: cannot access '/opt/poznote/init.sh': No such file or directory
The file itself is byte for byte the same and uses absolute paths only,
so running it from the new location changes nothing. Prefer docker/ and
fall back to the old path, since a container pinned to an older release
still has it there.
* pocketbase-bot: accept the var_ names and two missing fields
cpu, ram, hdd, os and version were already reachable, but only under
the PocketBase names. People type what the ct scripts call them, so
"/pocketbase <slug> var_ram=4096" was rejected as an unknown field
while "ram=4096" worked. The bot already carried the mapping as
RESOURCE_TO_CT_VAR, for display only.
Normalise the keys in parseKVPairs, so both the field=value path and
the method path accept them, along with disk and memory as the other
two names people reach for. Matching is case-insensitive.
pin_reason and last_update_commit exist on the record and are worth
editing, but were not in ALLOWED_FIELDS. slug, script_created and
script_updated stay out: the first is the key the command looks the
record up by, the other two belong to the timestamp workflow. notes and
install_methods keep their own subcommands.
* pocketbase-bot: write the sync PR against the PR template
The sync PR body had its own Summary and Source headings, so the
autolabeler found none of the template checkboxes it looks for and the
PR came out with nothing but "needs triage". It also never referenced
the issue the command came from.
Write the body the way the template expects, with the Website update
box ticked, which is what a PocketBase sync is. Tested thoroughly stays
unticked and Tested on says not tested, because nothing here was run;
close-invalid-pr-template skips bot authors, so that costs nothing.
Reference the triggering number as Fixes when the command came from an
issue and as a plain mention when it came from a PR comment, where
Fixes would point the PR at itself. issue_comment carries both under
github.event.issue, so the new IS_PR_COMMENT tells them apart.
* ci: stop the .app header PR being closed as a new script
allowedBots carried "community-scripts-pr-app" but not the
"[bot]"-suffixed name GitHub actually reports, and the check is an exact
match, so the exemption never applied to it. push-app-to-main is listed
both ways; this one was not. PR #17304 was closed as an untested new
script submission because of it.
generate-app-headers.sh empties ct/headers, tools/headers and
vm/headers and writes them again, so every run reports those files as
added. That is what the autolabeler's new-script rule looks for, and
the vm rule matched vm/headers too. Exclude the header directories from
both, and skip them in the close workflow's own added-file fallback, so
the label cannot come back by another route.
Checked against minimatch with the shipped config: header files get
neither label, ct/*.sh, install/*.sh and vm/*.sh still get theirs.
* pocketbase-bot: label the sync PR as a bugfix
The sync corrects CT defaults that no longer match the PocketBase
record, so bugfix describes it better than website update, which is
meant for metadata changes on the site itself.
community-scripts-pr-app[bot]