Bump docker-compose to v2.18.1

[rfay]

The Issue

Time to catch up to current docker-compose version

How This PR Solves The Issue

Bump to composer 2.18.1

See also

• v1.21.5: Large projects with many mounted files take way too long to start #4727

Manual Testing Instructions

Use it.

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR

[gilbertsoft]

Sounded promising but makes it even worse here. Also with a small project.

[rfay]

@gilbertsoft what does it make worse, and in what way?

[gilbertsoft]

@gilbertsoft what does it make worse, and in what way?

docker-compose build takes much longer now. It was already bad before since some versions, not sure when it changed to bad but some time ago ddev start was much faster than it is at the moment.

[rfay]

So you're saying that you tested this PR and were able to detect the difference in timing on build? Did you use ddev debug refresh to test it? Can you give an example of what your experience was?

There haven't been reports of build being the problem here; dockerr-compose was frozen at 2.15.1 because of #4727

I was wondering if perhaps there was a change about using buildx or something in recent docker-compose versions but I don't see anything there.

[gilbertsoft]

So you're saying that you tested this PR and were able to detect the difference in timing on build? Did you use ddev debug refresh to test it? Can you give an example of what your experience was?

There haven't been reports of build being the problem here; dockerr-compose was frozen at 2.15.1 because of #4727

For the test I did:

ddev start
ddev stop
ddev start

The first start asked for a poweroff which I did and that's why I did a stop and start again afterwards to have clean results only for the start with router and ssh agent already started and the docker-compose binary already downloaded and preset in the desired version.

To compare the time I've taken the last time track start before build and the next perf output after build:

v1.21.6 (16:30:54.899870360 -> 16:31:13.136306597 ~ 8.3 seconds)
v1.22.0-alpha2-60-gfa7a95f0 (16:23:16.347786863 -> 16:23:35.050146960 ~ 18,7 seconds)

I didn't do a debug refresh for the moment.

[rfay]

BTW, this can actually be tested easily without actually building; you can use ddev config global --required-docker-compose-version=v1.18.0 and that should be adequate to switch back and forth.

I do see in https://docs.docker.com/compose/environment-variables/envvars/ that we're using some unsupported environment variables still in

ddev/pkg/ddevapp/ddevapp.go

Lines 1903 to 1910 in c6518c3

	// Without COMPOSE_DOCKER_CLI_BUILD=0, docker-compose makes all kinds of mess
	// of output. BUILDKIT_PROGRESS doesn't help either.
	"COMPOSE_DOCKER_CLI_BUILD": "0",
	"COMPOSER_EXIT_ON_PATCH_FAILURE": "1",
	// The compose project name can no longer contain dots
	// https://github.com/compose-spec/compose-go/pull/197
	"COMPOSE_PROJECT_NAME": "ddev-" + strings.Replace(app.Name, `.`, "", -1),
	"COMPOSE_CONVERT_WINDOWS_PATHS": "true",

- but it doesn't seem like it would affect this.

[rfay]

On the Linux tests, there's no discernable difference in timing. For example, here's your Amplitude test:

And here's the 2.18.0 test:

[rfay]

I'm not seeing a difference in ddev start times on mac/colima, will try other environments:

[rfay]

@gilbertsoft I'm unable to recreate the problems you saw. I've done a full comparison at https://docs.google.com/spreadsheets/d/1SXlXanCoVw0SS_-viLueJ7DdJdjQUjrBT6819OW8pV4/edit?usp=sharing

The good news here is the numbers are all fine, and the macOS Docker Desktop numbers, which were horrible and probably the reason I was worrying about recent regressions, were fixed by a factory reset.