Make build_id param as required when updating CI minutes async
What does this MR do and why?
Related to #331785 (closed)
This is the 3rd out of 4 MRs related to making the update of CI minutes consumption idempotent.
In the previous MR !69994 (merged) we passed build_id
when invoking the worker that updates CI minutes consumption. Having the build_id
it means we can understand whether we have already added the CI minutes job consumption to the monthly consumption.
Now that build_id
is always passed in for every worker we can make it a required parameter.
This change has been performed over several MRs due to https://docs.gitlab.com/ee/development/sidekiq_style_guide.html#multi-step-deployment.
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
marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed
added typefeature label
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 Bogdan Denkovych ( @bdenkovych
) (UTC+3, 2 hours ahead of@fabiopitino
)David Fernandez ( @10io
) (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
- Resolved by Igor Drozdov
@zmartins could you please review?
requested review from @zmartins
requested review from @igor.drozdov
removed review request for @zmartins
@zmartins
, 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:
enabled an automatic merge when the pipeline for 809ffd45 succeeds
mentioned in commit df4ebb50
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
mentioned in merge request kubitus-project/kubitus-installer!306 (merged)
removed typefeature label
added releasedpublished label and removed releasedcandidate label