fix(compose): return nil error on non-zero container exit codes

[vmphase]

What I did

From my understanding, cli.StatusError means the container's command ran and exited non-zero. Hence, that's not a compose failure, but the command's own exit code. Returning a non-nil err alongside it made callers treat a normal exit as a tool error. Now it just passes the exit code through.

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[glours]

I think we should consider this from the public API perspective, not only from the Compose CLI behavior.

This changes the implementation of api.Service.Exec(ctx, projectName, options) (int, error). API clients may rely on receiving both the structured exit code and the original error value, and may inspect or wrap that error on their side. Returning (statusCode, nil) removes that context and makes it impossible for callers to recover any details carried by the original error.

Even if the current error often only contains the exit code, preserving it keeps the API more expressive for non-CLI consumers.

[vmphase]

I think we should consider this from the public API perspective, not only from the Compose CLI behavior.

This changes the implementation of api.Service.Exec(ctx, projectName, options) (int, error). API clients may rely on receiving both the structured exit code and the original error value, and may inspect or wrap that error on their side. Returning (statusCode, nil) removes that context and makes it impossible for callers to recover any details carried by the original error.

Even if the current error often only contains the exit code, preserving it keeps the API more expressive for non-CLI consumers.

Fair. However, IMO, returning both a non-zero status code and a non-nil error for a successful exec (where the command exited non-zero) is ambiguous. Callers have to decide whether to treat the error/status code as authoritative. Might be worth documenting the current behavior explicitly.