1.9 KiB
1.9 KiB
| 所属任务 | 任务标题 | 需求 | 状态 |
|---|---|---|---|
| 工单机器人 | 规范化DevOps | 写文档熟悉工作流 | 已完成 |
| Gitea->Jira同步 (目前是单向的) |
1.用映射表相互转换二者不同格式的json,并写帮助文档 | 已完成 | |
| 2.实现单向同步内容当前为: 工单->问题 工单正文->描述 里程碑->迭代 标签-类型->类型 标签-紧急程度->优先级 指派人->经办人 工单状态->工单建立时,待办;指派时,处理中;关闭时,已完成;重开时,处理中 |
处理中 | ||
| 3.二者评论区由工单机器人发送另一平台的源链接 | 已完成 | ||
| 4.宕机重试机制:由用户主动在评论区发起重试,可用/resync命令 | 已完成 | ||
| 5.Gitea附件流式传输到Jira | 已挂起 | ||
| 6.熔断机制,遭到攻击或者万一发生无限循环,需要一个熔断器打断机器人所有进程 | 处理中 | ||
| 7.多例仓库模式 | 处理中 | ||
| 8.根据用户唯一标识和名称共同判断机器人操作防止无限循环(熔断兜底) | 已挂起 | ||
| 9.内存锁机制,防止单个工单多个并发导致重复创建问题 | 已完成 | ||
| 10.Gitea的文本是markdown格式,要转换成Jira自己的格式,防止文本格式错乱 | 已完成 | ||
| 11.异步日志记录 | 已完成 | ||
| 自测bug和设计缺陷 | 1.经办人匹配模糊度过高(fixed:先精确匹配,匹配失败再模糊匹配) 2.内存锁超时释放时间应动态调整(fixed,计数器加时) 3.签名验证不强制,可能收到非法webhook(fixed:强制验证) 4.高并发不熔断有被攻击风险(fixed:可自定义的熔断机制) 5.边界条件:payload缺少issue,repo字段,空payload,空标题,长标题,特殊字符标题,unicode和emoji,null描述(持续处理) |
持续处理 |