eb2d20665f
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: ![Screen_Shot_2016-09-05_at_6.45.32_PM](/uploads/a82bfaf316661091e383b743a2f11334/Screen_Shot_2016-09-05_at_6.45.32_PM.png) ## 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 |
||
---|---|---|
.. | ||
api | ||
assets | ||
backup | ||
banzai | ||
ci | ||
container_registry | ||
gitlab | ||
json_web_token | ||
omni_auth | ||
rouge/formatters | ||
support | ||
tasks | ||
banzai.rb | ||
disable_email_interceptor.rb | ||
event_filter.rb | ||
extracts_path.rb | ||
file_size_validator.rb | ||
file_streamer.rb | ||
gitlab.rb | ||
gt_one_coercion.rb | ||
repository_cache.rb | ||
static_model.rb | ||
unfold_form.rb | ||
uploaded_file.rb | ||
version_check.rb |