amsd-pipeline 2.0.4 → 2.0.6

package/install.sh

@@ -888,6 +888,13 @@ else
     # symptom of the crash — same bug CLASS as the dashboards live/ directory fixed above, here for
     # ./data and ./spool specifically.
     mkdir -p "$LAUNCH_DIR/data" "$LAUNCH_DIR/spool"
+    # ...and make them writable by the uid the CONTAINER runs as. Creating them as the host user
+    # is the whole fix under docker, where those uids are the same. Under rootless podman they are
+    # not, and the mkdir above reproduces the very failure this block exists to prevent.
+    # ./data is the container's own database — it may own that outright.
+    ensure_bind_mount_ownership "$LAUNCH_DIR/data"
+    # ./spool is the boundary the HOST runner writes; it must stay writable from both sides.
+    ensure_shared_bind_mount "$LAUNCH_DIR/spool"
 
     _LD_PORT="$(grep -E '^LAUNCH_UI_PORT=' "$LAUNCH_DIR/.env" 2>/dev/null | tail -1 | cut -d= -f2)"
     _LD_PORT="${_LD_PORT:-8099}"
@@ -933,8 +940,22 @@ else
         # containers carrying NO network aliases — `getent hosts postgres` unresolved, so langfuse
         # could never reach its database however healthy postgres reported itself. The mock stack
         # has been seeded with "$ROOT-mock" since it was added; this one never was.
+        # RECREATE, DO NOT REUSE. `up -d --build` leaves an EXISTING container alone even when the
+        # compose file that defined it has changed — the same trap the observability stack's
+        # compose_up was fixed for, where reused containers came up with no network aliases. Live
+        # 2026-09-07 under podman-compose: launch-ui kept a stale image and a stale network mode
+        # after both were changed, so the install re-tested exactly what it had just replaced and
+        # reported the old failure. A down first costs seconds and makes the up mean something.
         for _LD_SUBNET in $(isolated_subnet_candidates "$ROOT-launch"); do
             _LD_TRY_PORT=$((_LD_PORT + _LD_I * 10))
+            # EVERY ATTEMPT STARTS CLEAN. `up -d --build` leaves an EXISTING container alone, so a
+            # retry's new port/subnet is silently ignored and the stack stays on the previous
+            # attempt's values — live 2026-09-07: attempt 0 published 8099, attempt 1 raised the
+            # port to 8109, compose reused the containers, and the installer then health-checked
+            # 8109 while the dashboard answered perfectly on 8099. The same trap the observability
+            # stack's retry was already fixed for; this loop never got it.
+            (cd "$LAUNCH_DIR" && container_compose -f "$LAUNCH_COMPOSE" -p "$_LD_PROJECT" down) \
+                >/dev/null 2>&1 || true
             if (cd "$LAUNCH_DIR" && LAUNCH_SUBNET="$_LD_SUBNET" LAUNCH_UI_PORT="$_LD_TRY_PORT" \
                     container_compose -f "$LAUNCH_COMPOSE" -p "$_LD_PROJECT" up -d --build) >"$_LD_LOG" 2>&1; then
                 _LD_UP=0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "amsd-pipeline",
-  "version": "2.0.4",
+  "version": "2.0.6",
   "description": "Installer for the amsd-pipeline orchestration stack. Clones, packages and provisions the full stack with one command — no separate git clone step.",
   "bin": {
     "amsd-pipeline": "bin/amsd-pipeline.js"