cli-plugins/hooks: max-message enforcement is off by one

从 cli-plugins/hooks/template.go 的第 43 行和第 46 行开始，使用 issue 中的 11 行复现代码检查 hooks.ParseTemplate()。添加一个回归测试，表明 10 个换行符会被拒绝，而处于 10 条消息限制以内的输出仍然有效；完成的标准是没有额外的行被合并到最终消息中。

Description

cli-plugins/hooks.ParseTemplate() currently enforces maxMessages = 10 by counting newline characters and rejecting only when strings.Count(out, "\n") > maxMessages, then returning strings.SplitN(out, "\n", maxMessages).

That makes the limit off by one:

• a template that renders to 10 newline characters actually contains 11 messages
• that output is currently accepted instead of rejected
• SplitN(..., 10) then merges the extra line into the last returned element, so the final "message" can still contain an embedded newline

This means the "maximum 10 messages" guard can be bypassed by one extra rendered line.

Reproduce

1. Use the current master branch.
2. Call hooks.ParseTemplate() with output that contains 11 lines, for example:

strings.Repeat("line\n", 10) + "line"

3. Observe that no error is returned.
4. Observe that the returned slice has length 10, with the last element containing an embedded newline.

The relevant logic is currently in:

• cli-plugins/hooks/template.go:43
• cli-plugins/hooks/template.go:46

Expected behavior

A template that renders to more than 10 messages should be rejected, including the 11-line / 10-newline case.

In other words, the limit should be enforced on the number of returned messages, not just on the number of newline separators.

docker version

N/A for runtime environment. This is a source-level issue in the current master branch checkout.

Observed in local checkout at 9f16882de4.

docker info

N/A for runtime environment. This issue is in template parsing logic and does not depend on daemon configuration.

Additional Info

This looks like it was introduced by b7ab63387a (cli-plugins/hooks: limit maximum number of lines / messages).

I’m happy to send a fix with a regression test if this behavior matches the intended bug report.