Windows installer: payload hash-locking, SBOM, client-IP handling, operator docs
This commit is contained in:
@@ -17,40 +17,31 @@ 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
|
||||
)
|
||||
# Shared with the Windows builder (deploy/windows/installer/build-installer.ps1)
|
||||
# so both stage the same set from the same profile.
|
||||
CLOSURE=$(python3 "$REPO/scripts/resolve_plugin_closure.py" "$PROFILE" "$REPO")
|
||||
|
||||
echo "Site profile: $PROFILE"
|
||||
echo "Plugin closure: $CLOSURE"
|
||||
|
||||
# Frontend: build carrying only the closure's plugins.
|
||||
echo "==> Building frontend (SITE_PLUGINS=$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.
|
||||
@@ -64,6 +55,60 @@ 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/"
|
||||
# ONLY web.config, not all of deploy/. Two reasons, and the first is fatal:
|
||||
# the Windows builder stages its output at deploy/windows/installer/bundle, so
|
||||
# copying deploy/ wholesale recursed into the destination and cp aborted with
|
||||
# "cannot copy a directory into itself" - the documented build could not finish.
|
||||
# Second, the rest of deploy/ is installer SOURCE (scripts, artwork, MSIs); none
|
||||
# of it belongs in an application tree that gets copied onto a server.
|
||||
# shopdb-install.ps1 reads it from exactly this path.
|
||||
if [ -f "$REPO/deploy/windows/web.config" ]; then
|
||||
mkdir -p "$OUT/deploy/windows"
|
||||
cp -a "$REPO/deploy/windows/web.config" "$OUT/deploy/windows/"
|
||||
fi
|
||||
|
||||
# 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; 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
|
||||
|
||||
@@ -71,3 +116,8 @@ 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"
|
||||
|
||||
Reference in New Issue
Block a user