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>
This Architecture Decision Record was generated following trying out the
stale PR that attempted to add profiles that didn't work for me and was
conflicted with latest master. The ADR/plan was generated by discussion
with claude code. Seems like a reasonable approach to me.
A la lazygit, we can now navigate between panels using numbers
(1,2,3,4,5,6,7)
Add translation for number navigation
reformat
oops
fix translation case & generate docs
pluralize networks
It took me a fair bit of time before i understood that '{{ .DockerCompose }}' was defined by the dockerCompose var in commandTemplates.
In hindsight it is VERY obvious.. so i just wanted to contribute a comment that would have been useful to me when i first tried to set this up.
Some containers may have bash installed but some have only basic sh (Ash/Dash).
There is other shells too: ZSh, tsh etc.
We can automatically detect what shell is configured.
See explanation how it works https://github.com/moby/moby/issues/41702
