Allow docker-compose files to override the LGTM service#223
Conversation
Replace the `include:` directive with multiple `-f` flags when merging docker-compose files. The `include:` approach treats each file as an independent project, preventing service overrides across files. Multiple `-f` flags allow later files to merge into services defined by earlier files. Also adds `--project-directory` based on the first user compose file so that relative paths (build contexts, dockerfiles) resolve correctly.
There was a problem hiding this comment.
Pull request overview
This PR updates how OATS generates the final docker-compose file so that user-provided compose files can override the built-in lgtm service definition (needed for OBI/eBPF scenarios), while also ensuring relative paths in user compose files resolve correctly during the merge step.
Changes:
- Replaced the
include:-based merge approach withdocker composeusing multiple-fflags to enable service overrides across files. - Added
--project-directory(derived from the first user compose file) when runningdocker compose ... configto resolve relative build contexts/dockerfiles correctly. - Removed the now-unused embedded
docker-compose-include-base.ymlfile.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
yaml/generator.go |
Switches compose merging to multiple -f flags and sets --project-directory for correct relative path resolution. |
yaml/docker-compose-include-base.yml |
Removes the deprecated include: base file used by the previous merge approach. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // uses docker compose to merge templates (multiple -f flags allow service overrides) | ||
| args := []string{"compose"} | ||
| // Set project directory from the first user compose file so that relative | ||
| // paths (build contexts, dockerfiles, etc.) resolve correctly. | ||
| if len(compose.Files) > 0 { | ||
| args = append(args, "--project-directory", filepath.Dir(compose.Files[0])) | ||
| } | ||
| for _, file := range files { | ||
| args = append(args, "-f", file) | ||
| } | ||
| args = append(args, "config") |
There was a problem hiding this comment.
The new docker compose merge behavior (ordering of multiple -f files and --project-directory selection) isn’t covered by unit tests. generator_test.go currently only exercises joinComposeFiles, while the production path uses docker compose ... config and now relies on --project-directory to make relative build contexts/dockerfiles resolve correctly. Consider extracting argument construction into a small helper and adding a unit test that asserts the arg list (base template first, user compose files later, and --project-directory derived from the first user compose file).
Address PR review feedback by extracting the docker compose argument construction into a testable helper function with unit tests covering both with and without user compose files.
Summary
include:directive with multiple-fflags when merging docker-compose filesinclude:approach treats each file as an independent project, preventing service name overrides across files (fails withservices.lgtm conflicts with imported resource)-fflags allow later files to merge into services defined by earlier files--project-directorybased on the first user compose file so that relative paths (build contexts, dockerfiles) resolve correctlyMotivation
This is needed for docker-otel-lgtm OBI support, where the OATS compose file must override the
lgtmservice to addprivileged: true,pid: "host", andENABLE_OBI: "true"for eBPF instrumentation.Test plan
oats examples/obi) passes with this change