lazydocker/pkg/commands/docker_test_helpers_test.go
Tim Abell 9545538106
Add docker-compose profile support
Implements the design captured in docs/adr/0001-docker-compose-profile-support.md
(jesseduffield/lazydocker#423). Profiles render as pseudo-projects in the
project panel; selecting one filters the services and containers panels to
the services that activate with that profile, and Up/Down/Restart on the
selection use docker compose --profile X invocations.

Key choices:

- Profile is a flag on Project (IsProfile bool), not a new type. Avoids a
  generic-type split across the SideListPanel and CommandObject.

- Reuse existing command templates (Up, Down, DownWithVolumes, Restart,
  AllLogs, DockerComposeConfig). NewCommandObject appends --profile X when
  a profile context is set, so no separate UpProfile/DownProfile/... family
  is needed. Adds a new Restart template (master had no project-level
  restart at all).

- Discovery via 'docker compose config --profiles' and
  'docker compose --profile X config --services', cached on DockerCommand
  for the session. Soft-fails on error (logs once, caches empty) so the UI
  degrades to "no profile rows" rather than popping an error.

- Per-profile service filtering uses the local project and the profile's
  service set (default services + profile-X services, per docker semantics).

- No new keybinding for project/profile restart in this PR; handler exists
  for follow-up discussion.

- New unit tests cover NewCommandObject --profile injection, GetProfiles
  caching, GetProfileServices caching, and the soft-fail path.

fixes: https://github.com/jesseduffield/lazydocker/issues/423

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-19 14:48:50 +01:00

21 lines
781 B
Go

package commands
import (
"github.com/jesseduffield/lazydocker/pkg/config"
"github.com/sirupsen/logrus"
)
// newTestDockerCommand assembles a DockerCommand suitable for unit-testing the
// profile-discovery and command-templating logic in isolation. It populates
// just the fields those code paths touch: Config (with default user templates),
// Log, and the runOutput injection seam used in place of the real OSCommand
// shellout.
func newTestDockerCommand(runOutput func(string) (string, error)) *DockerCommand {
userCfg := config.GetDefaultConfig()
return &DockerCommand{
Log: logrus.NewEntry(logrus.New()),
Config: &config.AppConfig{UserConfig: &userCfg},
InDockerComposeProject: true,
runOutput: runOutput,
}
}