Skip to content

Add queue page #291

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

Merged
merged 1 commit into from
Jun 3, 2025
Merged

Add queue page #291

merged 1 commit into from
Jun 3, 2025

Conversation

Sakib25800
Copy link
Contributor

This PR does the following:

  • Adds /queue/<repo_name> page
    • Displays PR statistics
    • Displays queue in table with columns: number, status, mergeable, approved by, priority, rollup
    • The following columns have not been added (will make PRs for each):
      • Title (as we do not track this)
      • Head ref (same reason as above)
      • Assignee (same reason as above)
  • Redirects homepage to /queue/rust
  • Moves original homepage to new /help page

@Sakib25800
Copy link
Contributor Author

You'll notice a lack of styling because I figured there's no point in adding it as I plan to mock up some slight redesign iterations, and for now, the logic is more important.

Copy link
Contributor

@Kobzol Kobzol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR, and for splitting it into self-contained commits! Left a few comments, but overall the structure looks good.

bors is configured to use. (e.g. for the Rust project this is <code>@bors</code>)
Note that bors will only recognize comments in <i>open</i> PRs.
bors is configured to use. (e.g. for the Rust project this is
<code>@bors</code>) Note that bors will only recognize comments in
Copy link
Contributor

@Kobzol Kobzol Jun 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not currently the case with bors, right? I think it will happily run commands even in closed/merged PRs right now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh yeah, right now it will.

Homu deletes PRs from in-memory state and the database once merged and then skips webhook calls for these since they no longer exist to it.

I'm assuming we should do something similar? In which case that statement will become true but right now it's not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we really need to delete PRs from the database, but in the long term we might implement something like that to reduce the DB storage, yeah (although I suspect it will be so small anyway that it doesn't really matter).

@@ -251,6 +251,18 @@ pub enum BuildStatus {
Timeouted,
}

impl Display for BuildStatus {
Copy link
Contributor

@Kobzol Kobzol Jun 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine for now (keep it like it is), but I'd like to point out that the presentation of the build status should ideally be implemented in each presentation layer (currently we only have one - the website). It's possible that we might want to render it in different ways at multiple places, and probably the logic for deciding the visualization shouldn't live in the database module.

It can be done by creating a function in the website module that renders the status, or creating some helper presentation wrapper (e.g. BuildStatusTableDisplay) that would wrap the status and implement Display itself.

Implementing Display on the core "domain" types is a bit of an anti-pattern, even though it's quite tempting to do, and we already did it for other structs (but there we kind of abuse Display to serialize the structs form/into the DB 😆).

Path(repo_name): Path<String>,
State(state): State<ServerStateRef>,
) -> Result<impl IntoResponse, AppError> {
let repo = match state.db.repo_by_name(&repo_name).await? {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should fetch the repo from the app state (repositories where the GitHub app is installed), not from the DB. Because right now when you open bors with an empty DB, and it is installed on repository X, it will display "repository not found", because that repo doesn't yet have any entry in the DB (it is currently only created when the tree is closed, or some other similar operation).

Or, alternatively (and I think that this would be even better, because then we wouldn't need to consider the edge case where a known repo is not in the DB), when the bot starts and fetches the repositories where it is installed, it should eagerly upsert all the found repos into the DB. Could you please do that in a separate PR? Thank you!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working on it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this can be resolved.

@Kobzol
Copy link
Contributor

Kobzol commented Jun 3, 2025

Let me know if you want to merge #291 (comment) first, or if we should first merge this, doesn't really matter. If you want to merge this PR first, please squash the commits.

@Sakib25800
Copy link
Contributor Author

Will merge that PR first then come back to this.

@Sakib25800
Copy link
Contributor Author

Just realised that they're two completely separate PRs now.

I was going to fetch repos from state rather than the database but realised that we need TreeState anyway, so we have to fetch from the database regardless.

Squashed.

- Add queue table
- Add queue statistics
- Redirect homepage to queue page
- Replace original homepage with /help page
Copy link
Contributor

@Kobzol Kobzol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, great work!

@Kobzol Kobzol added this pull request to the merge queue Jun 3, 2025
Merged via the queue into rust-lang:main with commit 9c568c7 Jun 3, 2025
2 checks passed
@Kobzol Kobzol mentioned this pull request Jun 20, 2025
18 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants