mirror of
https://github.com/fosrl/pangolin.git
synced 2026-07-17 07:04:36 -05:00
[GH-ISSUE #2473] Frequent breaking changes in database build & migration commands cause repeated installer and update failures #30004
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MickLesk on GitHub (Feb 13, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2473
Describe the Bug
Over the last 2–3 weeks, Pangolin has changed its database generation and build workflow multiple times (at least 3–4 times), including renaming, removing, and reintroducing npm scripts such as:
These changes are not backward-compatible, often land without stable coordination, and repeatedly break fresh installs, updates, and automation scripts that rely on a predictable build and migration process.
As a result, downstream installers and update scripts are in a constant state of reactive fixes, even though no functional changes were intended on our side.
This is not an isolated incident — it is a recurring pattern tied directly to upstream changes in Pangolin’s build and database workflow.
Environment
OS Type & Version: Debian 13 (LXC)
Pangolin Version: Affected across multiple versions (1.12.x → 1.15.x)
Gerbil Version: Various
Traefik Version: 3.x
Newt Version: As bundled
Olm Version: As bundled
To Reproduce
To Reproduce
Perform a fresh install or run an update using an installer that worked days earlier.
Pangolin installation or update fails with one of the following patterns:
Expected Behavior
Pangolin should provide a stable, documented, and versioned database build & migration interface.
Breaking changes to build or DB generation commands should:
Installers and update scripts should not require emergency fixes every few days just to keep Pangolin operational.
By the way, it was never mentioned in any of the current release notes; there were always only direct commits, which makes it impossible to work with.
@oschwartz10612 commented on GitHub (Feb 14, 2026):
Hey, thanks for bringing this up. It is a valid complaint and we should
do better about being consistent and documenting. Right now we are
mostly officially supporting the docker container so thats why we do not
spend much time supporting native deployments but this could change.
Right now you need to set the type first and it should work like in the
Dockerfile:
LMK if that helps