Skip to content

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

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

lunny
Copy link
Member

@lunny lunny commented May 25, 2025

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.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label May 25, 2025
@lunny lunny added the type/refactoring Existing code has been cleaned up. There should be no new functionality. label May 25, 2025
@github-actions github-actions bot added the modifies/go Pull requests that update Go code label May 25, 2025
@github-actions github-actions bot added the modifies/api This PR adds API routes or modifies them label May 25, 2025
@lunny lunny marked this pull request as ready for review May 26, 2025 00:18
lunny added a commit that referenced this pull request May 26, 2025
Extract from #34531. This will reduce unnecessary count operation in
databases.

---------

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
@lunny lunny added this to the 1.25.0 milestone May 26, 2025
@ChristopherHX
Copy link
Contributor

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
Copy link
Contributor

  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
Copy link
Member Author

lunny commented May 27, 2025

  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?

  1. 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
Copy link
Contributor

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
Copy link
Member Author

lunny commented May 27, 2025

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
Copy link
Contributor

wxiaoguang commented May 27, 2025

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
Copy link
Contributor

wxiaoguang commented May 27, 2025

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
Copy link
Member Author

lunny commented May 27, 2025

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.

@github-actions github-actions bot added the modifies/templates This PR modifies the template files label May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. modifies/api This PR adds API routes or modifies them modifies/go Pull requests that update Go code modifies/templates This PR modifies the template files type/refactoring Existing code has been cleaned up. There should be no new functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants