mengw15 commented on PR #6274: URL: https://github.com/apache/texera/pull/6274#issuecomment-4919395723
**Design note — why a dedicated `smoke-boot.sh` rather than reusing `local-dev.sh up`:** The script doesn't reimplement how a service starts — it runs `bin/<service>`, the exact sbt-native-packager launcher that the prod deploy image's `CMD` and `local-dev.sh up` both run, reading the same `storage.conf`. So the launch and config don't drift across dev / CI / prod; the packaged artifact is booted the prod way. What the script adds is only the test harness: start → wait for the port to LISTEN → timeout → grep the log for `NoClassDefFoundError` / `LinkageError` / Jackson-module errors → kill. (Same idea as local-dev's own `tui_wait_panel` port-wait, just standalone.) `local-dev.sh up <service>` is the dev-stack *orchestrator* — it builds, brings up its own docker infra (the `texera-local-dev` compose), and exports dev creds (`texera/password`, `HOST_LAN_IP`). This job instead provisions infra via `services:` containers + this integration job's MinIO/LakeFS, and boots a *pre-built* dist shipped in as an artifact (`postgres/postgres`). Driving that through local-dev would mean overriding its env + `--skip-build` + bypassing its infra — arguably more glue (and more drift surface) than the thin harness. Booting the packaged artifact is, if anything, *closer to prod* than running the dev orchestrator. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
