ge-aerospace/shopdb-flask
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

build(site): also stage a subpath frontend build
Some checks failed
CI / backend (push) Failing after 2m1s
Details
CI / naming (push) Failing after 1s
Details
CI / frontend (push) Successful in 9s
Details
CI / migrations-mysql (push) Failing after 8s
Details

Browse Source 
Vite compiles the mount path into the bundle, so it cannot be chosen at install
time from a single build - a page served under /shopdb would load and then
request its assets from /assets/, and render nothing.

build-site.sh now produces both:
  frontend-dist           base /        - the app on its own IIS site
  frontend-dist-subpath   base /<alias> - an IIS Application under an existing
                          site, e.g. http://<server-fqdn>/shopdb/

SUBPATH_ALIAS (default 'shopdb') is fixed per bundle and written into the staged
build as .alias, so the three places that must agree - the IIS application alias,
MOUNT_PATH in .env, and this compiled base - cannot drift apart. The installer
checks that marker and refuses rather than serving a page that cannot load.

The subpath build runs FIRST and is held in a temp dir: the root build has to be
last so frontend/dist is left in the state a developer expects, and the copy into
$OUT has to happen after the staging step that does rm -rf "$OUT".
This commit is contained in:
Cameron Proudlock
2026-08-03 01:55:21 -04:00
parent 0fa5f1e910
commit 4d5b6c3c55
1 changed files with 20 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
scripts/build-site.sh
View File

@@ -49,8 +49,24 @@ PY
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 +80,8 @@ 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