Improve approach for linking merge requests to issues for cycle analytics calculations
The Plan metric in cycle analytics is not helpful. Once an issue is triaged in some way (Issue stage) is begins the Plan stage, however this consistently shows an impossibly short period of time in GitLab projects, and is likely the same for customers.
|Issue||6 mins||< 1 min||2 mins|
|Plan||4 days||6 days||7 days|
Also when viewing the list of issues that are being considered,
gitlab-ee report only one issue, while
We don't have enough data to show this stage.
The issue is caused by
first_mentioned_in_commit_at only being set if the issue is explicitly mentioned in a commit message.
first_mentioned_in_commit_at to be set in the following two situations:
- a commit message is pushed explicitly mentions the issue (existing)
first_mentioned_in_commit_atto the authored date of the commit
- when a merge request is merged and explicitly closes the issue
first_mentioned_in_commit_atto the authored date of the first commit in the merge request
The merge request widget allows issues to be closed by mentioning the issue in a commit message or in the merge request description. The cycle analytics logic should be consistent.