SonarQube 7.9.2 issue创建日期与代码提交日期不匹配原因排查求助

当前观测到的现象完全匹配SonarQube 7.9.2版本的分支分析机制特性，核心原因与推导方向一致：系统判定2021年4月29日9:35的分析为当前分支维度的首次有效分析，因此触发了issue创建日期的重置逻辑，未按常规规则匹配对应代码的Git提交日期。

2021年4月9日的上一次分析未被系统纳入历史关联范围，是因为7.9版本对短期分支的默认清理规则：

• 版本默认设置短期分支超过7天未活跃就会自动删除分支关联的所有历史快照、issue映射关系
• 4月9日到4月29日间隔20天，远超过默认的清理阈值，之前的分支分析、issue关联数据已经被系统自动清除
• 当4月29日重新对该分支发起分析时，系统检索不到任何该分支的历史关联数据，直接将本次分析判定为分支首次分析

可通过以下3步直接确认根因：

• 查询服务端分支记录
  登录SonarQube的后端数据库，查询目标项目、目标分支的元数据：如果4月9日对应的分支记录已被物理删除，仅留存4月29日新建的分支UUID记录，即可直接确认历史数据已被清理。
• 查询异常issue的元数据
  定位所有显示日期异常的issue对应的数据库记录，如果这些issue的creation_date字段完全等于4月29日的分析执行时间，且关联的分支UUID和4月29日新建的分支UUID完全匹配，即可确认是首次分析逻辑触发的日期重置。
• 核对分支保留周期配置
  进入项目设置的分支配置页面，查看短期分支的保留时长配置，如果配置值小于20天，即可匹配数据清理的触发条件。

观测到的“所有日期异常的issue集中在同一个代码文件”的特征，完全符合上述根因的表现：

• 系统清理分支历史数据时，仅会删除和被清理分支直接关联的issue、文件映射关系
• 当分支被判定为首次分析时，系统会对所有检测到的issue重新打标创建日期为当前分析时间，不会回溯匹配Git提交记录
• 其他未被清理映射关系的关联文件，对应的issue仍会保持常规的创建日期匹配逻辑，因此仅单文件出现异常的特征，和数据清理的作用范围完全匹配

• 若该分支属于需要长期保留历史记录的协作分支，可将其标记为长期分支，系统将不会对其触发短期分支的自动清理逻辑，后续分析的issue会正常匹配Git提交日期
• 若该分支属于临时短期分支，可根据团队分支的平均存活时长调整短期分支的保留周期，避免分支间隔较久重新触发分析时被判定为首次分析，出现日期显示异常

内容的提问来源于stack exchange，提问作者Rémi