-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Introduce combined status #34531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Introduce combined status #34531
Conversation
Extract from #34531. This will reduce unnecessary count operation in databases. --------- Co-authored-by: wxiaoguang <[email protected]>
Thanks I can understand this new combine logic much better, less places of code that are potentially affected if a new commit status is added. At first glance this looks good to me. A skipped GitHub Actions job also does seems to report a success status in the commit list, so I think this is the right way forward. |
|
You can see, this PR also fixed some wrong tests. Even a warning was considered as a final status but not be found. This new introduced concept will reduce possible wrong when updating code in the future. The merged status now will be limited as 3 (failure, success and pending). I think you are right they can work to reuse these status but it need to do it carefully. But if we can reduce the possibility to do it wrong, why not?
If we introduced CombinedStatus but not change the struct name, so that we have 3 concepts, commit status, summary and combinedstatus. I don't think it's necessary to keep the |
I only see more problems and inconsistencies by this PR. For example: |
I will change the template variables. And for the database table name |
TBH I don't think these changes are right or necessary. To clearly answer your comments:
I do not see why it would go wrong. Only a few special APIs need to strictly follow GitHub's statues codes. For these places, we could simply add a "convert" function to narrow commit status down to GitHub's failure/success/pending. We can freely use our status states internally. Even if you do introduce a new "CombinedStatus" system, then you need to spend more time to split the frontend code (tmpl&vue) to support CommitStatus and CombinedStatus separately, then a lot of new copy-paste code.
I do not see why CommitStatusSummary means CombinedStatus. CommitStatusSummary is a summary, CombinedStatus(State) is just one of its fields. |
To address the FIXMEs in #34507 , in the future we should replace most "CalcCommitStatus (or your CalcCombinedStatus)" calls with the "CommitStatusSummary" records. If I understand correctly, I can see the original design (Add commit status summary table to reduce query from commit status table (#30223)) is that "when a commit status is inserted or updated, the summary should also gets updated". So in most cases, we could/should just get the "summary" for the commit, and render it by frontend. Then no need to play any trick with "CalcCommitStatus (or your CalcCombinedStatus)". I don't know why this original design became semi-finished and was not properly used. Keeping patching code is the root cause for various bugs. |
Yes, you are totally right. But when #30223 doesn't handle legacy records in commit_status. My next step is to migrate old records from commit_status to commit_status_summary then we can just read the table |
The commit status and combined commit status are different but the previous implementation mixed them because they are similar. We need to diff between
commit status
andcombined status
to make the logic more clear.Commit Status
A
commit status
was submitted by API or actions. For every commit and every context, it can be submitted multiple times. All of them will be recorded in the tablecommit_status
, but only the last submission is the current state of some context in a commit.A
Commit Status
could have "pending", "success", "error", "failure", "warning".Skipped
will not be introduced in this PR, it could be introduced in #34507Combined Status
A
combined status
is the merge of the last submittedcommit status
for the final result which could be displayed in commit list or dashboard. For every commit, there will only be one record, the following submitted will update the record.There is already a table
commit_status_summary
which has the same meaning ofCombined Status
. This PR will rename the struct toCombinedStatus
but keep the table name as before to keep compatible. The rename could be another PR.A
combined status
should have onlyfailure
,pending
andsuccess
.Combine commit status to Combined status
According to https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#get-the-combined-status-for-a-specific-reference
This PR will follow that rule and remove the
NoBetterThan
logic.