Files
shopdb-flask/scripts/build-site.sh
cproudlock 888b15a7dd build(site): stage a deployable tree and the profile in build-site.sh
build-site.sh staged only shopdb/, the chosen plugins/ and frontend-dist, so the
output could be imported but not run or migrated. The Windows installer had to
assemble wsgi.py, requirements.txt, migrations/ and deploy/ separately, which
meant it could assemble a payload whose plugin set did not match the profile the
tree was staged from.

Stage those runtime files, and copy the profile in as site-profile.json so the
set is self-describing: `flask plugin apply-profile` at provisioning reads the
same profile the tree was built from, so installed plugins and shipped plugin
code cannot drift.

frontend-dist keeps its name; CI reads that path (ci.yml:79).

The closing hint now spells out `prune-schema --yes --force`. ADR-014's prose
says lean provisioning "uses --force", but --force alone only permits dropping
non-empty tables; without --yes the command is a dry run that prints a preview
and exits, so following the ADR literally silently skips the prune.
2026-08-02 16:08:42 -04:00

96 lines
3.8 KiB
Bash
Executable File

#!/bin/bash
# Build a LEAN per-site artifact from a site profile (ADR-013 Phase 5).
#
# A site declares its plugins in a profile (deploy/site-profile.example.json).
# This resolves the hard-dependency closure, builds the frontend carrying only
# those plugins (via SITE_PLUGINS -> scripts/stage-frontend.mjs), and stages a
# backend tree containing core + only the chosen plugin dirs. A plugin a site
# did not choose ends up in neither the bundle nor the image.
#
# Usage: scripts/build-site.sh <site-profile.json> [output-dir]
set -euo pipefail
REPO="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
PROFILE="${1:?usage: build-site.sh <site-profile.json> [output-dir]}"
OUT="${2:-$REPO/build/site}"
[ -f "$PROFILE" ] || { echo "profile not found: $PROFILE"; exit 1; }
# Resolve the chosen plugins + their hard-dependency closure from the manifests.
CLOSURE=$(python3 - "$PROFILE" "$REPO" <<'PY'
import json, sys, os
profile_path, repo = sys.argv[1], sys.argv[2]
chosen = json.load(open(profile_path)).get('plugins', [])
plugins_dir = os.path.join(repo, 'plugins')
def deps(name):
mpath = os.path.join(plugins_dir, name, 'manifest.json')
if not os.path.exists(mpath):
sys.exit(f'profile plugin not found on disk: {name}')
out = []
for dep in json.load(open(mpath)).get('dependencies', []):
# name-only (strip any PEP440 range)
for sep in '><=!~ ':
dep = dep.split(sep)[0]
out.append(dep.strip())
return out
closure, seen = [], set()
def add(name):
if name in seen: return
seen.add(name)
for d in deps(name): add(d)
closure.append(name)
for p in chosen: add(p)
print(','.join(closure))
PY
)
echo "Site profile: $PROFILE"
echo "Plugin closure: $CLOSURE"
# Frontend: build carrying only the closure's plugins.
echo "==> Building frontend (SITE_PLUGINS=$CLOSURE) ..."
( cd "$REPO/frontend" && SITE_PLUGINS="$CLOSURE" npm run build --silent )
# Backend: stage core + only the chosen plugin dirs.
echo "==> Staging backend into $OUT ..."
rm -rf "$OUT"
mkdir -p "$OUT/plugins"
# cp (not rsync) so a minimal runner/deploy box without rsync can stage;
# bytecode is pruned afterwards to match the old --exclude filters.
cp -a "$REPO/shopdb" "$OUT/"
for name in ${CLOSURE//,/ }; do
cp -a "$REPO/plugins/$name" "$OUT/plugins/"
done
cp -r "$REPO/frontend/dist" "$OUT/frontend-dist"
# Runtime files a deployable tree needs beyond the Python packages. Without these
# the staged tree can be imported but not actually run or migrated, so the
# Windows installer (which consumes this output as its app\ payload) had to
# assemble them separately - and could assemble a tree whose plugin set did not
# match the profile it was built from.
cp "$REPO/wsgi.py" "$REPO/requirements.txt" "$OUT/"
cp -a "$REPO/migrations" "$OUT/"
[ -d "$REPO/deploy" ] && cp -a "$REPO/deploy" "$OUT/"
# Stage the profile INTO the tree. This is what makes the set self-describing:
# `flask plugin apply-profile` at provisioning time reads the same profile the
# tree was staged from, so the installed plugin set and the shipped plugin code
# cannot drift. It is also what `flask plugin prune-schema` effectively keys off
# (via what ends up installed), so a mismatch here would drop the wrong tables.
cp "$PROFILE" "$OUT/site-profile.json"
find "$OUT" -type d -name '__pycache__' -prune -exec rm -rf {} +
find "$OUT" -type f -name '*.pyc' -delete
echo ""
echo "Lean site staged at: $OUT"
echo " backend plugins: $(ls "$OUT/plugins" | tr '\n' ' ')"
echo " (a plugin not listed is absent from both the backend tree and the bundle)"
echo " profile staged as: $OUT/site-profile.json"
echo ""
echo "At provisioning, after 'flask db upgrade' and 'flask plugin upgrade-all':"
echo " flask plugin apply-profile site-profile.json"
echo " flask plugin prune-schema --yes --force # ADR-014; BOTH flags required"