[cvas22]

I added nerdctl compose events, one of the Compose commands still listed as unimplemented in the command reference (tracked in #3867).

nerdctl compose events [SERVICE...] shows the events of the project's containers, or only those of the given services. It reuses system.Events, so --format and --filter work as in nerdctl events and the output is the same as nerdctl events, which is not compatible with Docker (the command says so in its help).

The only change to the events code is a new optional LabelsMatcher in SystemEventsOptions. When it is set, the container labels are always looked up and only events of containers it accepts are printed; events that don't belong to a container are dropped. The compose command matches the compose project label and the service label of the selected services. I did not use a label= filter for this, because several label filters are OR'ed and the project and the service have to match together.

Changes:

• cmd/nerdctl/compose/compose_events.go: the command
• pkg/cmd/system/events.go, pkg/api/types/system_types.go: LabelsMatcher
• pkg/composer/composer.go: ProjectName()
• docs/command-reference.md: documented the command and removed it from the unimplemented list

Notes

• TestComposeEvents starts compose events svc1 in the background, runs compose up -d for two services and checks that only the events of svc1 are shown. I could only compile it locally (GOOS=linux go vet), so I'm relying on CI to run it.
• --since/--until and Docker's --json are not implemented, because nerdctl events does not have them either.

[cvas22]

compose events was holding the global compose lock while streaming, so I release it before streaming now, same as compose logs (2bac568). The test was still timing out after that, so in c4f6b67 it kills the containers with plain nerdctl kill instead of compose kill. Let me see what CI says.

[cvas22]

The kill is quick now, but the events command still prints nothing in CI and I can't reproduce it locally. I pushed a temporary debug commit to see what it receives, I'll drop it once I know what's going on.

[cvas22]

Found it. The debug run showed compose events only subscribed ~11s after starting because parallel compose tests were holding the compose lock, so the kill happened before it was listening. I dropped the debug commit and made the test NoParallel in 4df1824, and it passes now. The remaining failures (apparmor, init, ipc, TestKubeCommitSave) are the same ones failing on main.