Pull request check list is limited to 30 entries

[diorcety]

Description

This is linked to the DEFAULT_PAGING_NUM value.
The computation of the check summary status is also wrong due to this limit: A status can be in progress and the summary value having the value "All checks were successful"

Gitea Version

1.19

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Docker

Database

PostgreSQL

[diorcety]

Increasing DEFAULT_PAGING_NUM fix the issue: all checks are displayed and the summary status is correct

[CaiCandong]

I've understood the error, I made a PR to fix this.

[yp05327]

Is it possible to fix this by:

1. Using Int type to save CommitStatus in DB
2. Using min in sql to get the CommitStatus instead of CalcCommitStatus
3. Adding a pager bar in web ui

The logic now is loading all CommitStatus (limited 30) into memory from db, and get the minimum value of the status defined in CommitStatusPriorities in CalcCommitStatus.
If we use ListAll, all CommitStatus objects will be loaded into memory.
I think this can be done by db side, then we can avoid loading them into memory and calculating them.

[CaiCandong]

Is it possible to fix this by:

1. Using Int type to save CommitStatus in DB
2. Using min in sql to get the CommitStatus instead of CalcCommitStatus
3. Adding a pager bar in web ui

The logic now is loading all CommitStatus (limited 30) into memory from db, and get the minimum value of the status defined in CommitStatusPriorities in CalcCommitStatus. If we use ListAll, all CommitStatus objects will be loaded into memory. I think this can be done by db side, then we can avoid loading them into memory and calculating them.

I agree with you. But this requires more changes to be made and also involves changes to the database structure.