Make website bootstrap helper importable in Odoo shell startup

[cbusillo]

Objective

Fix the CM testing startup failure where the devkit runtime scripts generate Odoo shell snippets that import odoo_website_bootstrap, but the Odoo shell process cannot resolve /volumes/scripts/odoo_website_bootstrap.py on sys.path.

Why This Is The Right Repo

Launchplane successfully published and applied a fresh CM artifact that includes odoo-devkit main at bae74b93c111d597a0827284608b72e85658c164. Live Dokploy/Traefik route state is present, but the Odoo web container is restarting before it can serve traffic.

The failure is inside the devkit runtime startup path, not the Launchplane route/apply path.

Live Evidence

Fresh artifact:

• publish run: https://github.com/cbusillo/odoo-tenant-cm/actions/runs/25634663925
• artifact_id: artifact-cm-48094d7cee46aa28
• image_digest: sha256:48094d7cee46aa2836831e6f019510573584c5c1fb83ad35b1dcf2282fd819e2
• devkit runtime_repo_commit: bae74b93c111d597a0827284608b72e85658c164

Launchplane apply after route fixes:

• apply run: https://github.com/cbusillo/launchplane/actions/runs/25635383414
• deployment_record_id: deployment-20260510T174113Z-cm-testing
• target: cm-testing / y4uXgXQ6zwjWz8_Na7pfq
• runtime_identity_injected: true
• post_deploy_status: pass
• public verification failed because /web/health returned HTTP 404

Read-only Launchplane/Dokploy follow-up:

• plan run: https://github.com/cbusillo/launchplane/actions/runs/25635422437
• plan_status: ready
• latest Dokploy deployment: done
• runtime_identity_deployment_record_id: deployment-20260510T174113Z-cm-testing
• source_type: raw
• compose_file_sha256: f6f01e173ac941e249a9a4f52501053bdcf1e9ab79e10d8ae1946cfae751d903

Live deploy-host inspection:

compose-input-wireless-driver-dlcvpg-web-1  ghcr.io/cbusillo/odoo-tenant-cm  Restarting (1)

Container state:

State=restarting
Restarting=true
ExitCode=1
Networks=compose-input-wireless-driver-dlcvpg_default dokploy-network

The container has the expected Traefik labels, including routes for cm-testing.shinycomputers.com, so ingress metadata is not the immediate missing piece.

Crash log excerpt:

[platform-startup] database already initialized; skipping init
[platform-startup] running environment overrides
Traceback (most recent call last):
  File "/odoo/odoo-bin.source", line 6, in <module>
    odoo.cli.main()
  ...
  File "<string>", line 2, in <module>
ModuleNotFoundError: No module named 'odoo_website_bootstrap'
[platform-startup] fatal: Command '['/odoo/odoo-bin', 'shell', '-c', '/tmp/platform.odoo.conf', '-d', 'cm', '--db_host=database', '--db_port=5432', '--db_user=odoo', '--db_password=...', '--no-http']' returned non-zero exit status 1.

The helper exists in the container:

/volumes/scripts/odoo_website_bootstrap.py
/volumes/scripts/run_odoo_startup.py
/volumes/scripts/run_odoo_data_workflows.py

But normal runtime import lookup cannot see it:

PYTHONPATH=
spec= None

Read-only confirmation of likely fix direction:

PYTHONPATH=/volumes/scripts python3 - <<'PY'
import importlib.util
spec = importlib.util.find_spec("odoo_website_bootstrap")
print("spec_found=" + str(spec is not None))
print("origin=" + (spec.origin if spec else ""))
PY

Result:

spec_found=True
origin=/volumes/scripts/odoo_website_bootstrap.py

Suspected Narrow Fix

Update the devkit runtime shell execution path so Odoo shell subprocesses can import helpers mounted under /volumes/scripts.

Likely options:

• In docker/scripts/run_odoo_startup.py and docker/scripts/run_odoo_data_workflows.py, ensure the Odoo shell subprocess env prepends /volumes/scripts to PYTHONPATH.
• Or inject /volumes/scripts into sys.path inside generated Odoo shell snippets before importing odoo_website_bootstrap.

Preference: subprocess env fix if it matches local patterns, because it covers both startup and data workflow Odoo shell calls consistently.

Acceptance Criteria

• run_odoo_startup.py can run environment overrides when odoo_website_bootstrap.py lives in /volumes/scripts.
• run_odoo_data_workflows.py --bootstrap can import the same helper in Odoo shell snippets.
• Tests cover the helper import path for generated Odoo shell execution, not just direct script import in unit tests.
• A fresh CM artifact can be published and applied; cm-testing web container remains up instead of restarting on ModuleNotFoundError.
• After Launchplane reruns apply/bootstrap, public checks can proceed to the actual website health/canonical/page/logo assertions.

Related

• Blocks Add service-backed Odoo stable bootstrap workflow launchplane#542
• Blocks Add safe Odoo stable target replacement workflow launchplane#520
• Follow-up to Add Odoo website bootstrap support for Launchplane #34 / PRs Add Odoo website bootstrap support #35 and Persist controller-route website homepage bootstrap #36