feat: add Compose profiles support to containers view

[Vijay (h3110Fr13nd)]

Closes #570
Implements compose profile scope prompts, optimizes tree item sorting and UI formatting, and adds exclusive service scoping for Docker Compose profile actions.

[Vijay (h3110Fr13nd)]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

Adds Docker Compose profiles awareness to the Containers view by grouping profile-scoped services under profile “folders”, surfacing profile info in container tooltips/descriptions, and enabling compose actions to be scoped at the profile level.

Changes:

• Introduces ComposeProfileGroupTreeItem and composes profile-based subtrees under compose project groups.
• Adds compose profile discovery via docker compose config --format json and uses it to tag/group services and show profile info in tooltips.
• Extends compose group commands/menus to run against either a compose project group or a compose profile group (with a scope prompt).

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
extensions/vscode-containers/src/tree/containers/ContainerTreeItem.ts	Adds “shared” indicator in description and includes compose profiles in tooltip rendering.
extensions/vscode-containers/src/tree/containers/ContainerGroupTreeItem.ts	Builds profile subtrees under compose project groups; updates sorting/ancestor logic for mixed children.
extensions/vscode-containers/src/tree/containers/composeProfiles.ts	New helper to derive compose profiles via docker compose config --format json.
extensions/vscode-containers/src/tree/containers/ComposeProfileGroupTreeItem.ts	New tree item representing a compose profile group and exposing service scoping helpers.
extensions/vscode-containers/src/commands/containers/composeGroup.ts	Allows compose commands to target either a compose project group or a profile group, with scope prompting.
extensions/vscode-containers/package.json	Enables compose group context menu commands on the new profile-group tree items.

Suppressed comments (4)

extensions/vscode-containers/src/tree/containers/composeProfiles.ts:74

• Logging the first part of docker compose config output can inadvertently expose expanded environment values/secrets to the output channel. Prefer logging only metadata (e.g. length) and only at debug level.

        ext.outputChannel.appendLine(`[DEBUG] getComposeServiceProfiles stdout: ${stdout?.substring(0, 200)}...`);

extensions/vscode-containers/src/tree/containers/composeProfiles.ts:115

• This function intentionally falls back when config --format json isn't available, so logging it as an error is noisy. Prefer debug-level logging (and stringify the error) when falling back.

        ext.outputChannel.error(`getComposeServiceProfiles failed: ${err}`);

extensions/vscode-containers/src/commands/containers/composeGroup.ts:76

• services scoping for the "down" action will currently pass service names to docker compose down, which the DockerComposeClientBase builds directly (see packages/vscode-container-client/src/clients/DockerComposeClientBase/DockerComposeClientBase.ts) and Docker Compose does not accept. This will cause the command to fail for the "services"/"exclusive" scopes. Consider forcing "profile" scope for down (or implementing service-scoped teardown via different commands).

        // Ask the user whether to apply the command with the profile flag (which includes default
        // services too), only to the explicit service names in this profile (excluding defaults),
        // or strictly to services exclusive to this profile.
        const scope = await pickComposeProfileCommandScope(context, node, commandName);
        if (scope === 'profile') {

extensions/vscode-containers/src/commands/containers/composeGroup.ts:162

• composeGroup already has unit tests, but the new profile scoping logic (profile vs services vs exclusive) and the updated getComposeGroupLabels behavior (searching through profile sub-groups) aren't covered. Consider adding focused unit tests for these new branches to prevent regressions.

async function pickComposeProfileCommandScope(context: IActionContext, node: ComposeProfileGroupTreeItem, commandName: string): Promise<'profile' | 'services' | 'exclusive'> {
    const exclusiveNames = node.getExclusiveServiceNames();

    const picks: IAzureQuickPickItem<'profile' | 'services' | 'exclusive'>[] = [
        {

[Vijay (h3110Fr13nd)]

have carefully taken profile views as subtree/branches making services in a profile groups appear in view for appropriate distinction. some design decision(may change)

• showing each services of the profile, even repeated ones in their profile group.
  • however have added profiles in description clearly indicating how many profiles a service is in
  • and all the actions have the three options which may avoid/prevent unnecessary disaster.
• giving 3 options for actions, include default, profile only, exclusive profile only
  • I believe all use case of anyone gets covered in it, individual service action work as before
• all the project level behaviour remains as is. command action only applies to default. (people may not like transition from default behaviour or adding in an extra step at project level). feature is additive only.

Brandon Waterloo [MSFT] (@bwateratmsft) can you check whether there are nuances i've missed or i'm offtrack in assuming. feel free to suggest and change as appropriate.

ps. it's funny how most llm model disagrees when asked whether we can compose down specific while we can do it.

[Brandon Waterloo [MSFT] (bwateratmsft)]

Vijay (@h3110Fr13nd) can you add some screenshots and/or videos of the new stuff in action?

[Vijay (h3110Fr13nd)]

Brandon Waterloo [MSFT] (@bwateratmsft) while creating a video i realized the i've tested logs a little less, and they didn't provided service level scoping let alone profile level scoping, added them in the last commit and verified and here's a video on how it looks.

Screencast.From.2026-08-06.01-19-46-hevc.mp4

Once again project level commands behaviour remain as is. and haven't been changed.

[Buddy Maness (TwistedCrafts)]

look good