Track shared runners duration when job completes
What does this MR do and why?
Related to #254231 (closed)
In this MR we introduce a FF ci_always_track_shared_runners_usage
that enables tracking of shared_runners_duration
when a job completes.
Today when a job completes we track the amount of CI minutes consumed as job.duration * runner cost_factor
. Until this MR we only tracked amount_used
but for old public projects we currently use a cost_factor: 0
which means that we don't count CI minutes consumption in this scenario. However, we would like to know how long the namespace used shared runners for, regardless of the CI minutes billing. This is why we added tracking of shared_runners_duration
separately from CI minutes even when CI minutes consumption is 0
.
Screenshots or screen recordings
These are strongly recommended to assist reviewers and reduce the time to merge your change.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Merge request reports
Activity
changed milestone to %14.4
assigned to @fabiopitino
- A deleted user
added backend label
1 Message CHANGELOG missing: If you want to create a changelog entry for GitLab FOSS, add the
Changelog
trailer to the commit message you want to add to the changelog.If you want to create a changelog entry for GitLab EE, also add the
EE: true
trailer to your commit message.If this merge request doesn't need a CHANGELOG entry, feel free to ignore this message.
Reviewer roulette
Changes that require review have been detected!
Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:
Category Reviewer Maintainer backend Albert Salim ( @alberts-gitlab
) (UTC+8, 7 hours ahead of@fabiopitino
)Mikołaj Wawrzyniak ( @mikolaj_wawrzyniak
) (UTC+2, 1 hour ahead of@fabiopitino
)To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
DangerSetting label(s) devopsverify sectionops based on grouppipeline execution.
added devopsverify sectionops labels
mentioned in merge request !72315 (merged)
- Resolved by Fabio Pitino
changed milestone to %14.5
- Resolved by Bob Van Landuyt
- Resolved by Bob Van Landuyt
@avielle could you please review? Note that the MR still depends on !72315 (merged) to be merged first.
requested review from @avielle
- Resolved by Bob Van Landuyt
- Resolved by Bob Van Landuyt
- Resolved by Bob Van Landuyt
removed review request for @avielle
@avielle
, thanks for approving this merge request.This is the first time the merge request is approved. To ensure full test coverage, a new pipeline has been started.
For more info, please refer to the following links:
marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed
mentioned in issue #254231 (closed)
@reprazent could you do the maintainer review?
requested review from @reprazent
@fabiopitino This looks good to me! I think we can proceed. I just had one thought, but I don't think we should address it here: I think the naming
ci_minutes
andconsumption
is a bit confusing. I like calling that number "consumption" better because it's not really a duration in minutes anymore. Do you think this is something we should change and consistently apply?@reprazent It's a discussion we had in the past when we started to introduce cost factors which moved away from CI minutes being actual minutes (duration). We also are not consistent in the documentation on how to refer to this.
It's something we are iterating on and definitely something we are aware of.
enabled an automatic merge when the pipeline for 1140452e succeeds
mentioned in commit 7154f335
added workflowstaging-canary label
added workflowstaging label and removed workflowstaging-canary label
added workflowcanary label and removed workflowstaging label
added workflowproduction label and removed workflowcanary label
added releasedcandidate label
added releasedpublished label and removed releasedcandidate label