From 888b15a7dd3688e69bb7d1360c073a24b145b461 Mon Sep 17 00:00:00 2001 From: cproudlock Date: Sun, 2 Aug 2026 16:08:42 -0400 Subject: [PATCH] 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. --- scripts/build-site.sh | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/scripts/build-site.sh b/scripts/build-site.sh index de38160..b6d29b3 100755 --- a/scripts/build-site.sh +++ b/scripts/build-site.sh @@ -64,6 +64,23 @@ 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 @@ -71,3 +88,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"