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描述（持续处理） |
持续处理 |