Fix dev deployment: addons mount path + setup.sh build step#76
Merged
Conversation
Commit 6de6851 (Jan 2026, "move addon folder") moved the Odoo addons from the repo-root `addons/` to `odoo/addons/`. The `odoo/Dockerfile` was correct by accident (its `COPY addons /mnt/extra-addons` resolves relative to the build context `./odoo/`, so it copies from `odoo/addons/` into the image). But the docker-compose.yml volume mount `./addons:/mnt/extra-addons` remained unchanged and now points at a nonexistent path on fresh clones. Effect on fresh clones: the volume mount overlays the image's baked-in `/mnt/extra-addons` (which has openems, partner_firstname, web_m2x_options) with an empty host directory. Odoo starts with no custom modules. `setup.sh` tries to install the `openems` module and everything appears fine until it attempts to insert into `openems_device` — which fails with "relation does not exist" because that model's table was never created. Discovered during 2026-04-21 AWS dev env deployment: EC2 bootstrap cloned `local-deployment` fresh, hit the error, setup.sh failed. Works on existing developer laptops only because they have leftover pre-refactor files at the old path `./addons/`. Fix: point the mount at the real location `./odoo/addons/`. Preserves the dev ergonomic of editing addon files without rebuilding the image. Signed-off-by: Alejandro Malbet <amalbet@gmail.com>
The override generated by setup.sh for --edges N mode disables the
base `openems-edge` service (profiles: ["disabled"]) and creates N
numbered `openems-edge-0..N-1` services that reference
`image: openems-edge:latest` without a `build:` directive. This is
fine at runtime (the override is meant to fan out edges), but it
breaks the build step.
`docker compose build` (no flags) merges both compose files, sees the
override's "disabled" profile, and skips building openems-edge. The
numbered services don't declare a build either, so NO build of the
edge image happens at all. When `docker compose up` later tries to
start the numbered services, it tries to pull openems-edge:latest
from Docker Hub and fails:
Image openems-edge:latest Pulling
Image openems-edge:latest Error pull access denied for openems-edge,
repository does not exist or may require 'docker login'
This only surfaces on fresh systems where the image isn't already
cached from a prior build. Laptops with older cached images don't
hit it, which is why this bug sat undetected.
Fix: build with `-f docker-compose.yml` to ignore the override and
build all services from the base compose definition. Safe and
minimal; the override is still used for `up`.
Discovered during 2026-04-21 AWS dev env deployment.
Signed-off-by: Alejandro Malbet <amalbet@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two small fixes to unblock fresh-clone deployments of the
local-deploymentstack (both discovered during 2026-04-21 AWS dev env validation). The stack works on existing developer laptops but fails on any clean environment (new team member laptop, fresh EC2, CI runner).Two labeled commits, each self-contained:
1.
b18172c— fix(compose): addons volume mount pathCommit
6de6851(Jan 2026, "move addon folder") moved Odoo addons from repo-rootaddons/toodoo/addons/.odoo/Dockerfilewas incidentally correct (build context is./odoo/, so itsCOPY addonsresolves toodoo/addons/). Butdocker-compose.yml:94kept the old path and now overlays the image's baked-in modules with an empty host directory. Result: Odoo starts without theopenemsmodule, andsetup.shfails with "relationopenems_devicedoes not exist" when creating edge0.Fix:
./addons:/mnt/extra-addons→./odoo/addons:/mnt/extra-addons.2.
9b6289e— fix(setup): build images from base compose onlysetup.sh --edges Ngenerates adocker-compose.override.ymlthat disables the baseopenems-edgeservice (profiles: ["disabled"]) and replaces it with N numberedopenems-edge-0..N-1services that reference the image by tag without abuild:directive. Whendocker compose buildruns afterward, it merges both files, honors the disabled profile, and skips building openems-edge entirely. Whenuplater tries to start the numbered services it fails withpull access denied for openems-edge.Fix:
docker compose -f docker-compose.yml build— ignores the override at build time, still uses it atuptime.Test plan
git clean -fdx(or clone fresh) on an existing laptop./setup.sh --edges 2Context
These are part of a bundle of "AWS dev env unblocker" fixes. The Terraform-side fixes (B2B port 8082→8075, IMDSv2 token fetch) were pushed to #75 in separate labeled commits — see #75 for that side of the work. Those live in
iac/dev/and targetmain; these live at repo root and targetlocal-deployment. Different branches, so they had to split PRs.@aidan-barnes-axm — no AWS/infra changes here, purely docker-compose + setup.sh. Review at your convenience.