Addressing WAL for CommitStatus by only updating new mergeRequests
What does this MR do and why?
We're doing too many writes, the point of this MR is to see if/how we can decrease those writes.
Previously the head_pipeline for the merge_request was always set if the pipeline is the latest. Here we're changing that so it only sets if there's a new pipeline.
I believe this also might fix an existing bug, consider the case of two pipelines with the same sha.
pipeline1. sha - 123, created_at: 1.year.ago
pipeline2. sha - 123, created_at: today
Before MR: updating the status of pipeline1 via (/api/v4/projects/285/statuses/xyz?pipeline_id=1)
will promote pipeline1 to head_pipeline, even though it's from a year ago. This is contradictory to https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/finders/ci/pipelines_for_merge_request_finder.rb?ref_type=heads#L68
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
Related to #448713