我正在将CI / CD系统的结果/日志发布到Microsoft Teams。在处理一些失败的构建并获得更长的结果时,我偶然发现了webhook URL https://outlook.office.com/webhook/bb6bfee7-1820-49fd-b9f9-f28f7cc679ff@<uuid1>/IncomingWebhook/<id>/<uuid2>
返回的以下错误:
Webhook message delivery failed with error: Microsoft Teams endpoint returned HTTP error 413 with ContextId tcid=3626521845697697778,server=DB3PEPF0000009A,cv=BmkbJ1NdTkv1EDoqr7n/rg.0..
如我所见,这是由于发布到Teams Webhook URL的有效载荷过长所致。
当JSON有效负载超过18000个字符时,初始复杂消息(部分,标题,字幕,格式化的链接,<pre>
格式化的文本等)失败。
对有效负载进行一点测试,我发现从原始JSON有效负载中删除的格式越多,Teams消息的时间就越长。我可以发布的最长消息有(根据cu cURL):Content-Length: 20711
。此消息的JSON有效负载为:
{"themeColor":"ED4B35","text":"a....a"}
JSON格式的空格似乎不算在内(即添加空格不会减少我可以发送到Teams Webhook的最大邮件长度)。
作为参考,初始消息看起来与此类似:
{
"themeColor": "ED4B35",
"summary": "iris-shared-libs - shared-library-updates - failure",
"sections": [
{
"activityTitle": "Job: [iris-shared-libs](https://my.concourse.net/teams/hsm/pipelines/iris-shared-libs) - [shared-library-updates #89](https://my.concourse.sccloudinfra.net/teams/hsm/pipelines/iris-shared-libs/jobs/shared-library-updates/builds/89) (FAILURE)",
"activityImage": "https://via.placeholder.com/200.png/ED4B35/FFFFFF?text=F",
"facts": [
{
"name": "Failed step",
"value": "update-shared-libraries"
}
]
},
{
"text": "Trying a new strategy with gated versioned releases",
"facts": [
{
"name": "Repository",
"value": "[iris-concourse-resources](https://my.git.com/projects/IRIS/repos/iris-concourse-resources)"
},
{
"name": "Commit",
"value": "[2272145ddf9285c9933df398d63cbe680a62f2b7](https://my.git.com/projects/IRIS/repos/iris-concourse-resources/commits/2272145ddf9285c9933df398d63cbe680a62f2b7)"
},
{
"name": "Author",
"value": "me@company.com"
}
]
},
{
"activityTitle": "Job failed step logs part 1",
"text": "<pre>...very long log text goes here ...</pre>"
}
]
}
Microsoft Teams连接器Webhook发布消息的实际最大长度是多少?
official page没有提及。在底部的“反馈”部分中,还有一个关于“邮件大小限制?”的悬而未决的问题。反馈:“我们目前正在对此进行调查。”
答案 0 :(得分:1)
根据我到目前为止所做的测试,根据JSON消息有效负载(结构和格式),在18000到40000之间(<长度低于18000永不中断,而长度超过40000则始终中断。
删除JSON有效负载的一部分并在另一个JSON值中添加相同数量的字符将不会为您提供相同的最大值。
我已观察到最大部分数的软限制(消息被截断,但没有错误): 10 。从11号开始的部分将被丢弃。