All the code that pre-calculates metrics for use in the cycle analytics page. - Ci::Pipeline -> build start/finish - Ci::Pipeline#merge_requests - Issue -> record default metrics after save - MergeRequest -> record default metrics after save - Deployment -> Update "first_deployed_to_production_at" for MR metrics - Git Push -> Update "first commit mention" for issue metrics - Merge request create/update/refresh -> Update "merge requests closing issues"
The observed faulty state transition is probably hard to test,
because we need to hook into internal states to observe them.
Namely this:
07:30:16 | Build#ruby-2.2 enqueue: created -> pending
07:30:16 | Pipeline#32 enqueue: created -> pending
07:30:16 | Build#ruby-2.3 enqueue: created -> pending
07:30:16 | Build#ruby-2.2 run: pending -> running
07:30:16 | Pipeline#32 run: pending -> running
07:30:29 | Build#ruby-2.2 drop: running -> failed
07:30:29 | Pipeline#32 run: running -> running
07:30:29 | Build#ruby-2.3 run: pending -> running
07:30:30 | Pipeline#32 run: running -> running
07:30:57 | Build#gem:build skip: created -> skipped
07:30:57 | Pipeline#32 drop: running -> failed
07:30:57 | Build#gem:release skip: created -> skipped
07:30:57 | Pipeline#32 drop: failed -> failed
07:30:57 | Build#ruby-2.3 drop: running -> failed
07:30:57 | Pipeline#32 drop: running -> failed
^^^ Should be failed -> failed
However, the consequence of this, executing hooks twice would be
easy enough to observe. So we could at least test against this.
Keep in mind that if we ever changed how we execute the hooks
this won't be testing against faulty state transition.
Smartly calculate real running time and pending time ## What does this MR do? Try to smartly calculate the running time and pending time for pipelines, instead of just use wall clock time from start to end. The algorithm is based on: > Suppose we have A, B, and C jobs: > * A: from 1 to 3 > * B: from 2 to 4 > * C: from 6 to 7 > The processing time should be accumulated from 1 to 4, and 6 to 7, totally 4, excluding retires, and calculate on `%w[success failed running canceled]` jobs (if a job is not finished yet, assume it's `Time.now`) ## Are there points in the code the reviewer needs to double check? I would actually like to test `Gitlab::Ci::PipelineDuration#process_segments`, but it's a private method right now and it's not very convenient to test it. Is there a way to test it without changing the original code too much? Note that I would like to avoid saving merged segments because it's not used and should be garbage collected. ## Screenshots:  ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - Tests - [x] Added for this feature/bug ## What are the relevant issue numbers? Closes #18260, #19804 See merge request !6084