VSA report calculating cycle time incorrectly
Summary
The cycle time on the VSA report is being calculated based on the timestamp of the most recent commit instead of the timestamp first (oldest) commit. This is likely resulting in a significantly lower cycle time than reality within the VSA report. Internal Slack thread
Steps to reproduce
- This issue (https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules/-/issues/18) was created on
2021-08-11 4:28am EDT
. The MR was created on2021-08-11 11:03am EDT
. The MR was merged on2021-08-13 8:51am EDT
. The first commit pushed up was on2021-08-11 11:21am EDT
. - The cycle time for this issue shows
< 1s
because of this commit https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules/-/commit/9ce6ebee55efcaa4ff8fc5dc6ae7aaac84204f51, which automatically closed the issue. This is not the right commit to use for calculating the cycle time.
Example Project
This impacts all Groups and Projects likely. See "Steps To Reproduce" for specific links.
What is the current bug behavior?
The cycle time is not calculated correctly.
What is the expected correct behavior?
The cycle time is calculated by the MR creation date. If there is an earlier commit that can be associated to an issue, for example via relating a branch to an issue before an MR is opened, we should use this timestamp. In any event, it should always be calculated by the earliest possible timestamp related to any indicator that work on an issue has started.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Possible fixes
We need to fix the code which sets the first_mentioned_in_commit_at
: https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/issues/close_service.rb#L89
Let's use the authored date from the MR diff commits table. For the existing records, we can create a BG migration. Issue metrics records are possibly affected from 2020-02-19
.
Whenever we store the first_commit date, we look at the most recent commit. Instead of that, we should look at the oldest commit.