shopdb-flask/scripts/build-site.sh

#!/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.
# Kept in scripts/resolve_plugin_closure.py rather than inline, so the closure
# rules have one home and a second builder cannot drift from them.
CLOSURE=$(python3 "$REPO/scripts/resolve_plugin_closure.py" "$PROFILE" "$REPO")

echo "Site profile:  $PROFILE"
echo "Plugin closure: $CLOSURE"

# Frontend: TWO builds, because Vite compiles the mount path into the bundle and
# it therefore cannot be chosen at install time from a single build - the page
# would load and then request its assets from the wrong path.
#   dist          -> own IIS site (method A, the default)
#   dist-subpath  -> IIS Application under an existing site (method B)
# SUBPATH_ALIAS is fixed per bundle so the three places that must agree - the IIS
# application alias, MOUNT_PATH and this base - cannot drift apart.
SUBPATH_ALIAS="${SUBPATH_ALIAS:-shopdb}"
SUBPATH_TMP="$(mktemp -d)"
trap 'rm -rf "$SUBPATH_TMP"' EXIT

echo "==> Building frontend for /$SUBPATH_ALIAS/ (SITE_PLUGINS=$CLOSURE) ..."
( cd "$REPO/frontend" && SITE_PLUGINS="$CLOSURE" VITE_BASE_PATH="/$SUBPATH_ALIAS/" npm run build --silent )
cp -r "$REPO/frontend/dist" "$SUBPATH_TMP/dist-subpath"
echo "$SUBPATH_ALIAS" > "$SUBPATH_TMP/dist-subpath/.alias"

# Root build LAST, so frontend/dist is left in the state a developer expects.
echo "==> Building frontend for / (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"
# Staged after the rm -rf above, or it would be deleted with everything else.
cp -r "$SUBPATH_TMP/dist-subpath" "$OUT/frontend-dist-subpath"

# 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/"
# deploy/ is deliberately NOT copied. It holds deployment SOURCE - compose files
# and site profiles - and none of it belongs in an application tree that gets
# copied onto a server.

# A CycloneDX SBOM of everything this tree depends on, Python and npm together.
# Staged INTO the tree so it installs onto the server with the application: an
# air-gapped site cannot be scanned remotely, so the only way to answer "are we
# exposed to this CVE, and where" is for the answer to be sitting on the box.
# Generated from requirements.txt and package-lock.json, both already pinned and
# committed, so it is a translation rather than a scan - and deterministic.
echo "==> Generating SBOM ..."
python3 "$REPO/scripts/generate_sbom.py" "$REPO" -o "$OUT/sbom.cdx.json"

# Docs the RUNNING SITE serves or the operator needs on the box. Without
# openapi.json and llms.txt the self-hosted /api/docs page is broken on every
# installed server - which matters most for the sites least able to debug it, and
# for the operators who will point an assistant at their own instance. The
# Windows runbooks ship because an air-gapped server has no other way to reach
# them; docs/ is not otherwise staged, so shipping the whole tree would be noise.
echo "==> Staging docs ..."
mkdir -p "$OUT/docs"
for doc in openapi.json llms.txt api-inventory.json \
           INSTALL-WINDOWS.md OPERATE-WINDOWS.md BACKUP-RESTORE.md UPGRADE.md \
           FLOOR-MAP.md; do
  [ -f "$REPO/docs/$doc" ] && cp -a "$REPO/docs/$doc" "$OUT/docs/"
done
# Never let a missing optional doc fail the build - the loop's last test governs
# the exit status under `set -e`.
true

# 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"