Introduce combined status

[lunny]

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 and combined 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 table commit_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 #34507

Combined Status

A combined status is the merge of the last submitted commit 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 of Combined Status. This PR will rename the struct to CombinedStatus but keep the table name as before to keep compatible. The rename could be another PR.

A combined status should have only failure, pending and success.

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

Additionally, a combined state is returned. The state is one of:
failure if any of the contexts report as error or failure
pending if there are no statuses or a context is pending
success if the latest status for all contexts is success

This PR will follow that rule and remove the NoBetterThan logic.

[ChristopherHX]

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.

[wxiaoguang]

1. I don't think it's good to introduce a new commitstatus.CombinedStatusState system, I don't see any problem by reusing existing statuses. For example: We also reuse the statuses for action jobs and runs like Fix incomplete Actions status aggregations #32859
2. I don't think the name CommitStatusSummary has any problem. Renaming it only introduces more inconsistency and confuses developers.

[lunny]

1. I don't think it's good to introduce a new commitstatus.CombinedStatusState system, I don't see any problem by reusing existing statuses. For example: We also reuse the statuses for action jobs and runs like Fix incomplete Actions status aggregations #32859

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?

2. I don't think the name CommitStatusSummary has any problem. Renaming it only introduces more inconsistency and confuses developers.

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 CommitStatusSummary concept since it's the same as CombinedStatus.

[wxiaoguang]

I only see more problems and inconsistencies by this PR. For example: ctx.Data["CommitStatus"] = combinedStatuses, why you use "combined statuses" for "CommitStatus"? How to correctly maintain the templates?

[lunny]

I only see more problems and inconsistencies by this PR. For example: ctx.Data["CommitStatus"] = combinedStatuses, why you use "combined statuses" for "CommitStatus"? How to correctly maintain the templates?

I will change the template variables. And for the database table name commit_status_summary, since this is a refactor PR, I could send another PR to rename it to the new name.

[wxiaoguang]

TBH I don't think these changes are right or necessary.

To clearly answer your comments:

This new introduced concept will reduce possible wrong when updating code in the future. ... But if we can reduce the possibility to do it wrong, why not?

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 don't think it's necessary to keep the CommitStatusSummary concept since it's the same as CombinedStatus.

I do not see why CommitStatusSummary means CombinedStatus. CommitStatusSummary is a summary, CombinedStatus(State) is just one of its fields.

[wxiaoguang]

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.

[lunny]

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 commit_status_summary in all combined status needed UI. This should be performance improvements especially for commits list page. I can observe there are many queries from commit_status table in some repoisitories' commits list page.