chore(compose): update to compose-v5

[mdelapenya]

What does this PR do?

Upgrades the modules/compose module from Docker Compose v2 (github.com/docker/compose/v2) to v5 (github.com/docker/compose/v5), using the official SDK introduced in v5.

Key changes:

• Dependency upgrade: docker/compose/v2 v2.40.2 → docker/compose/v5 v5.1.0, compose-spec/compose-go/v2 bumped from v2.9.0 to v2.10.1
• Use LoadProject API: Replaced manual project compilation (cli.NewProjectOptions + compiledOptions.LoadProject) with composeService.LoadProject(ctx, api.ProjectLoadOptions{...}) from the v5 SDK
• Decoupled Docker clients: Compose v5 internally migrated from docker/docker/client to moby/moby/client, making the types incompatible. The compose service now uses its own Docker CLI client, while testcontainers provider and direct API calls use a separate testcontainers.NewDockerClientWithOpts() client
• Env file labels: Sourced from per-service s.EnvFiles (from the compose file's env_file declarations) instead of the old cli.ProjectOptions.EnvFiles
• Go version: Module bumped to go 1.25.0 (required by compose v5 transitive dependencies). CI workflow updated to skip modules on incompatible Go versions
• compose_local.go: determineVersion() now handles compose v5+ (treats majorVersion >= 2 as v2-style dash separator)

Files changed:

• modules/compose/compose.go — v5 imports, decoupled client initialization, removed makeClient
• modules/compose/compose_api.go — v5 imports, LoadProject API, env file labels from service config
• modules/compose/compose_api_test.go — v5 import
• modules/compose/compose_local.go — version detection for v5+
• modules/compose/go.mod / go.sum — dependency updates
• .github/workflows/ci-test-go.yml — Go version compatibility check to skip modules requiring newer Go

Why is it important?

• Docker Compose v2 is EOL and affected by GHSA-p436-gjf2-799p
• Compose v5 introduces an official SDK package, making the integration more stable for testcontainers-go
• The compose maintainers recommended migrating to v5 for third-party integrations

Related issues

• Closes user-reported request to update compose module to v5

How to test this PR

cd modules/compose
# Requires Go 1.25+
go test -count=1 -timeout 600s ./...

All 42 existing tests pass (2 skipped: TestDockerComposeAPIWithBuild and TestDockerComposeAPI_WithoutReaper).

Follow-ups

• The WithOsEnv() method is now effectively a no-op: compose v5's LoadProject always includes cli.WithOsEnv internally. Consider deprecating it
• The deprecated LocalDockerCompose (shell-based) was kept but could be removed in a future major release
• When the project bumps its minimum Go version to 1.25, the CI compatibility check for this module becomes unnecessary

[netlify]

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	444ed74
🔍 Latest deploy log	https://app.netlify.com/projects/testcontainers-go/deploys/69ac1e52a483640008f86a19
😎 Deploy Preview	https://deploy-preview-3568--testcontainers-go.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Summary by CodeRabbit

• Chores

  • Updated Go language requirement to 1.25.0
  • Upgraded Docker Compose module to v5 with corresponding API updates
  • Updated multiple dependencies including docker/cli, compose-go, and various transitive packages for compatibility

• Infrastructure

  • Enhanced CI/CD workflows with dynamic version selection based on Go version requirements
  • Added Go version compatibility checks in test pipelines with fallback warnings

Walkthrough

Adds Go-version gating to CI (lint/test), dynamically selects golangci-lint based on module Go version, migrates Docker Compose usage from v2 to v5 in the compose module with separate compose and testcontainers clients, and bumps the compose module Go requirement to 1.25.0 with many dependency updates.

Changes

Cohort / File(s)	Summary
CI / Workflows \.github/workflows/ci-lint-go.yml, \.github/workflows/ci-test-go.yml	Extract module Go version from go.mod; dynamically map to golangci-lint version; compare runner Go vs module Go and set compatible flag; gate multiple job steps on compatibility and emit warnings/skip behavior.
Compose module — core initialization modules/compose/compose.go, modules/compose/compose_api.go, modules/compose/compose_api_test.go	Migrate imports to docker/compose/v5; initialize Docker CLI with flags.NewClientOptions; create composeService and a distinct testcontainers Docker client; replace manual project option assembly with composeService.LoadProject.
Compose module — local helpers / minor refactors modules/compose/compose_local.go, docker_client.go, wait/errors.go	Micro-optimizations and cleanup: use strings.Builder for concatenations, pre-size slices for command construction, simplify build tags and version-determination switch.
Compose module — go.mod / deps modules/compose/go.mod, modules/azurite/go.mod	Bump module Go version to 1.25.0; upgrade docker/compose to v5 and numerous direct/transitive dependencies; smaller dependency bumps in azurite module.

Sequence Diagram(s)

mermaid
sequenceDiagram
participant CI as CI Workflow
participant Init as InitRoutine
participant Flags as flags.NewClientOptions
participant DockerCLI as Docker CLI
participant ComposeSvc as Compose Service (v5)
participant TestcontClient as testcontainers Client
participant Provider as Docker Provider

CI->>Init: run compose initialization
Init->>Flags: create client options
Flags->>DockerCLI: initialize Docker CLI with options
Init->>ComposeSvc: compose.NewComposeService(Docker CLI)
Init->>TestcontClient: testcontainers.NewDockerClientWithOpts()
TestcontClient->>Provider: inject separate docker client
ComposeSvc->>Provider: inject compose service
Provider->>Provider: ready with separated clients

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• fix(compose): update to docker compose v2.40.2 and use api.Compose interface #3456: Related compose API migration to newer docker/compose API and usage changes.
• docs(metrics): automate usage metrics collection and publish it in the docs site #3495: Related CI workflow edits (docker/setup-docker-action and workflow gating overlap).

Suggested labels

chore, dependencies, compose

Suggested reviewers

• stevenh

Poem

🐰 I hopped through modules, sniffed the Go,
I swapped v2 to v5 with a gentle toe.
CI checks the version, lint dances new,
Dependencies sprout in a fresher hue—
A carrot for builds, and a happy hop too.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: upgrading Docker Compose from v2 to v5 in the modules/compose module.
Description check	✅ Passed	The description is detailed and directly related to the changeset, explaining what is upgraded, why it matters, and how to test the changes.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

modules/compose/compose_local.go (1)

332-344: ⚠️ Potential issue | 🟡 Minor

Address golangci-lint prealloc warning.

Pipeline failure indicates execCmd should be preallocated with capacity 3 + len(args).

🔧 Proposed fix for prealloc

-	execCmd := []string{"Starting command", dirContext, binary}
-	execCmd = append(execCmd, args...)
+	execCmd := make([]string, 0, 3+len(args))
+	execCmd = append(execCmd, "Starting command", dirContext, binary)
+	execCmd = append(execCmd, args...)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@modules/compose/compose_local.go` around lines 332 - 344, The execCmd slice
is being appended without preallocating causing a golangci-lint prealloc
warning; change the initialization of execCmd in the block that builds the
command (the variable execCmd used to populate the returned ExecError) to
preallocate capacity with make([]string, 0, 3+len(args)) (so it holds the
initial three entries and all args) then append the dirContext, binary and args
as before; this resolves the prealloc warning while leaving the ExecError
construction (Command, StdoutOutput, StderrOutput, Error, Stderr, Stdout)
unchanged.

🧹 Nitpick comments (1)

modules/compose/compose_local.go (1)

121-125: Builder usage is slightly awkward but functionally correct.

The strings.Builder is created but the path separator is still concatenated via + before writing. A cleaner approach would write path and separator separately. However, this is a minor nit in deprecated code.

♻️ Optional: cleaner Builder usage

 var composeFileEnvVariableValueSb121 strings.Builder
 for _, abs := range dc.absComposeFilePaths {
-	composeFileEnvVariableValueSb121.WriteString(abs + string(os.PathListSeparator))
+	composeFileEnvVariableValueSb121.WriteString(abs)
+	composeFileEnvVariableValueSb121.WriteByte(os.PathListSeparator)
 }
 composeFileEnvVariableValue += composeFileEnvVariableValueSb121.String()

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@modules/compose/compose_local.go` around lines 121 - 125, The Builder usage
in compose_local.go is awkward: instead of concatenating the path separator with
the path string using + before calling WriteString on
composeFileEnvVariableValueSb121, iterate dc.absComposeFilePaths and call
WriteString(abs) followed by WriteByte(os.PathListSeparator) (or
WriteString(string(os.PathListSeparator))) to append the separator directly to
the strings.Builder; finally append composeFileEnvVariableValueSb121.String() to
composeFileEnvVariableValue as before. This change affects the loop that builds
composeFileEnvVariableValueSb121 and leaves dc.absComposeFilePaths and
composeFileEnvVariableValue unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/ci-lint-go.yml:
- Around line 38-47: The version selection logic around MODULE_GO_VERSION /
MODULE_MAJOR_MINOR is too coarse and may pick an incorrect golangci-lint release
for newer Go minors; replace the current single >= "1.25" branch with an
explicit mapping of supported MODULE_MAJOR_MINOR values (e.g., "1.20" -> v2.0.2,
"1.25" -> v2.5.0, "1.26" -> v2.10.0, etc.) implemented as a case/if-elif chain
that echoes the correct "version=..." to $GITHUB_OUTPUT for each known Go minor,
and add a fail-fast default that prints an error and exits nonzero when
MODULE_MAJOR_MINOR is not recognized so the workflow cannot silently select an
incompatible linter release.

In `@modules/compose/compose.go`:
- Around line 163-176: The NewDockerCompose function creates a testcontainers
provider and dockerClient but never closes them, causing resource leaks; add
resource cleanup by implementing a Close method on the DockerCompose type (e.g.,
func (d *DockerCompose) Close() error) that calls provider.Close() and
dockerClient.Close() (or the provider's Close which closes the underlying
client), and ensure Down() either calls this Close() or that callers invoke
Close() after Down(); update NewDockerCompose to store the created provider and
dockerClient on the DockerCompose struct (if not already) so Close() can access
them and return any close errors wrapped appropriately.

In `@modules/compose/go.mod`:
- Around line 122-131: Update the OpenTelemetry SDK dependency from v1.38.0 to
v1.40.0 (or later) to remediate GHSA-9h8m-3fm2-qjrq; specifically change the
module line for go.opentelemetry.io/otel/sdk in modules/compose/go.mod to
v1.40.0+ and run go mod tidy to refresh indirect dependencies (also verify
related otel packages like go.opentelemetry.io/otel,
go.opentelemetry.io/otel/trace, go.opentelemetry.io/otel/metric, and the otlp
exporters are compatible and updated as needed).

---

Outside diff comments:
In `@modules/compose/compose_local.go`:
- Around line 332-344: The execCmd slice is being appended without preallocating
causing a golangci-lint prealloc warning; change the initialization of execCmd
in the block that builds the command (the variable execCmd used to populate the
returned ExecError) to preallocate capacity with make([]string, 0, 3+len(args))
(so it holds the initial three entries and all args) then append the dirContext,
binary and args as before; this resolves the prealloc warning while leaving the
ExecError construction (Command, StdoutOutput, StderrOutput, Error, Stderr,
Stdout) unchanged.

---

Nitpick comments:
In `@modules/compose/compose_local.go`:
- Around line 121-125: The Builder usage in compose_local.go is awkward: instead
of concatenating the path separator with the path string using + before calling
WriteString on composeFileEnvVariableValueSb121, iterate dc.absComposeFilePaths
and call WriteString(abs) followed by WriteByte(os.PathListSeparator) (or
WriteString(string(os.PathListSeparator))) to append the separator directly to
the strings.Builder; finally append composeFileEnvVariableValueSb121.String() to
composeFileEnvVariableValue as before. This change affects the loop that builds
composeFileEnvVariableValueSb121 and leaves dc.absComposeFilePaths and
composeFileEnvVariableValue unchanged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3953cf13-9c7c-4cb2-b701-ba0d65a01531

📥 Commits

Reviewing files that changed from the base of the PR and between 32aac58 and 9c7caf6.

⛔ Files ignored due to path filters (1)

• modules/compose/go.sum is excluded by !**/*.sum

📒 Files selected for processing (7)

• .github/workflows/ci-lint-go.yml
• .github/workflows/ci-test-go.yml
• modules/compose/compose.go
• modules/compose/compose_api.go
• modules/compose/compose_api_test.go
• modules/compose/compose_local.go
• modules/compose/go.mod

[coderabbitai]

🧹 Nitpick comments (1)

modules/compose/compose_local.go (1)

121-125: Unusual variable name with numeric suffix.

The variable name composeFileEnvVariableValueSb121 contains what appears to be a line number suffix (121). This looks like a debugging artifact or typo. Consider renaming to something cleaner like composeFileEnvVariableValueBuilder or simply sb.

✨ Suggested rename

-	var composeFileEnvVariableValueSb121 strings.Builder
+	var sb strings.Builder
 	for _, abs := range dc.absComposeFilePaths {
-		composeFileEnvVariableValueSb121.WriteString(abs + string(os.PathListSeparator))
+		sb.WriteString(abs + string(os.PathListSeparator))
 	}
-	composeFileEnvVariableValue += composeFileEnvVariableValueSb121.String()
+	composeFileEnvVariableValue = sb.String()

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@modules/compose/compose_local.go` around lines 121 - 125, The variable name
composeFileEnvVariableValueSb121 is a stray/verbose identifier (likely from a
debug or line-number artifact) — rename it to a clear name like
composeFileEnvVariableValueBuilder (or sb) inside the function in
modules/compose/compose_local.go, update its declaration and the call sites
where WriteString and String() are used (the loop over dc.absComposeFilePaths
and the subsequent append to composeFileEnvVariableValue) so all references
match the new name; ensure imports remain unchanged and run tests/build to
verify no other references exist.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@modules/compose/compose_local.go`:
- Around line 121-125: The variable name composeFileEnvVariableValueSb121 is a
stray/verbose identifier (likely from a debug or line-number artifact) — rename
it to a clear name like composeFileEnvVariableValueBuilder (or sb) inside the
function in modules/compose/compose_local.go, update its declaration and the
call sites where WriteString and String() are used (the loop over
dc.absComposeFilePaths and the subsequent append to composeFileEnvVariableValue)
so all references match the new name; ensure imports remain unchanged and run
tests/build to verify no other references exist.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: da90a01a-89ca-4cd1-b268-36cacd91571d

📥 Commits

Reviewing files that changed from the base of the PR and between 9c7caf6 and 64e623f.

📒 Files selected for processing (1)

• modules/compose/compose_local.go

[coderabbitai]

🧹 Nitpick comments (1)

docker_client.go (1)

73-77: Variable name infoLabelsSb72 appears to be an automated refactoring artifact.

The 72 suffix looks like a line number remnant. Consider a cleaner name like labelBuilder or sb.

The change from in-loop string concatenation to strings.Builder is a valid performance improvement.

✨ Suggested variable rename

-		var infoLabelsSb72 strings.Builder
+		var labelBuilder strings.Builder
 		for _, lb := range dockerInfo.Labels {
-			infoLabelsSb72.WriteString("\n    " + lb)
+			labelBuilder.WriteString("\n    " + lb)
 		}
-		infoLabels += infoLabelsSb72.String()
+		infoLabels += labelBuilder.String()

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docker_client.go` around lines 73 - 77, The variable name infoLabelsSb72 is
an artifact; rename it to a clear name such as labelBuilder (or sb) in the block
where dockerInfo.Labels are iterated and appended to infoLabels, i.e., replace
infoLabelsSb72 with labelBuilder (create strings.Builder labelBuilder) and
update the WriteString and final infoLabels += labelBuilder.String() calls so
all references to infoLabelsSb72 are removed and use the new identifier.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@docker_client.go`:
- Around line 73-77: The variable name infoLabelsSb72 is an artifact; rename it
to a clear name such as labelBuilder (or sb) in the block where
dockerInfo.Labels are iterated and appended to infoLabels, i.e., replace
infoLabelsSb72 with labelBuilder (create strings.Builder labelBuilder) and
update the WriteString and final infoLabels += labelBuilder.String() calls so
all references to infoLabelsSb72 are removed and use the new identifier.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3e4f5858-abeb-4612-bad3-e4325069fee5

📥 Commits

Reviewing files that changed from the base of the PR and between 64e623f and 444ed74.

⛔ Files ignored due to path filters (1)

• modules/azurite/go.sum is excluded by !**/*.sum

📒 Files selected for processing (4)

• .github/workflows/ci-lint-go.yml
• docker_client.go
• modules/azurite/go.mod
• wait/errors.go

💤 Files with no reviewable changes (1)

• wait/errors.go

[mdelapenya]

Errors are not related to this PR, merging