/ 
Developer-Dashboard-2.17
/ Developer::Dashboard::DockerCompose

NAME

Developer::Dashboard::DockerCompose - compose resolver and launcher

SYNOPSIS

my $docker = Developer::Dashboard::DockerCompose->new(
    config  => $config,
    paths   => $paths,
    plugins => $plugins,
);

DESCRIPTION

This module resolves layered docker compose inputs into a final transparent docker compose command line and can optionally execute it.

METHODS

new, resolve, run

Construct, resolve, and optionally execute compose operations.

PURPOSE

This module resolves and runs dashboard-managed Docker Compose stacks. It maps wrapper flags to compose files under layered runtime config roots, infers service names, exports the effective docker config root, and builds the final docker compose command that the wrapper execs.

WHY IT EXISTS

It exists because dashboard-specific Compose resolution has more rules than a plain passthrough wrapper: isolated service folders, disabled markers, addon/mode selection, and layered runtime lookup all need one tested owner.

WHEN TO USE

Use this file when changing compose file discovery, wrapper-only flags, service inference, environment exports such as DDDC, or the dry-run versus exec behavior of the docker helper.

HOW TO USE

Feed the parsed wrapper arguments into this module and let it return or execute the effective docker compose command. Avoid rebuilding compose discovery logic in the CLI wrapper or in project-local scripts.

WHAT USES IT

It is used by the dashboard docker compose helper, by docker-focused tests, and by developers who keep Compose stacks under .developer-dashboard/config/docker/ instead of shell aliases.

EXAMPLES

Example 1:

perl -Ilib -MDeveloper::Dashboard::DockerCompose -e 1

Do a direct compile-and-load check against the module from a source checkout.

Example 2:

prove -lv t/10-extension-action-docker.t

Run the focused regression tests that most directly exercise this module's behavior.

Example 3:

HARNESS_PERL_SWITCHES=-MDevel::Cover prove -lr t

Recheck the module under the repository coverage gate rather than relying on a load-only probe.

Example 4:

prove -lr t

Put any module-level change back through the entire repository suite before release.