rust-lang / homu Goto Github PK

See:

• rust-lang/rust#59489
• rust-lang/rust#59489 (comment)

rust-lang/rust#62761 was merged without any apparent indicator of approval.

It would be pretty useful to display the time a PR has been testing for on the queue page. Probably in brackets after pending (or in place of), maybe in a different colour. Keeping it live with JavaScript would be a bonus.

It appears that sometimes, the result of a try build can trigger a merge to master. This seems to occur when the PR is approved between when the try build is started and when the Homu gets notified that the try build finished.

See: rust-lang/rust#61763 (comment)

Potential steps to reproduce (haven't tried this yet, but it fits with what happened on the referenced issue comment):

1. Start a try build (e.g. @botname try)
2. Approve the build (e.g. @botname r+)
3. Wait until the try build succeeds

When receiving the treeclosed message:

🌲 The tree is currently closed for pull requests below priority 1500, this pull request will be tested once the tree is reopened

It would be nice if the comment linked to where the treeclosed request was made. This link should already be available, as it's shown elsewhere:

click on treeclosed link at the top of Homu queue page and it redirected me to the comment that closed the tree

Currently, our two bots need to be commanded like r? @user but bors r=user. I have been tripped by this, and so did others.

Would be nice if bors could just strip the leading @ when encountering bors r=@user.

Currently, it is fairly easy to accidentally create a rollup containing an unapproved PR: all it takes is a wrong click in the long column of checkboxes on the left.

Would it be possible to disable/remove those checkboxes for PRs that are not actually enqueued, or else at least warn before creating a rollup that contains an unapproved PR?

I was surprised that on the dashboard, that only the PR number links to the PR. It would be nice if I could also just click on the title of the PR and have that redirect me to the PR like does on GitHub.

Another nice to have would also being able to click on the head ref, and people's names but that feels less important.

In the rare occasions we might want to merge even if CI has failed, we should explicitly command @bors to ignore the CI failure.

There are 3 types of comments that can be made related to a pull request:

1. Issue comments, which – despite their name – are comments made directly in the pull request. Most of our @bors commands are made here.
2. Review comments, which are comments made on the code diff of a merge request
3. Commit comments, which are comments made on the commit itself (and we do not support in @bors).

I wrote a script to go through all of our pull requests to quantify how many bors commands appear in review comments. Here are the results:

So, the only time this feature has been used (that I can find; I won't rule out that my code was not 100% perfect) was this 5 Dec 2018 comment.

In the spirit that the easiest code to maintain is no code, I propose that we remove support for this rarely used feature. The total cost of supporting it is pretty low, but the utility of this function appears even lower (one use in 5 years).

I believe it would mostly come down to removing the following two parts of the code:

I've been lucky enough to hit "422 Update is not a fast forward" twice in the past two weeks. Not sure if it makes sense to file an issue here (feel free to close). Cross referencing:

• rust-lang/rust#43535: Report on rust-lang
• servo/homu#24: Report on servo's homu.
• servo/homu#134: Attempt to add a retry

My recent encounters:

• rust-lang/rust#65941 (comment)
• rust-lang/cargo#7507 (comment)

Doesn't seem to happen too often: https://github.com/rust-lang/rust/pulls?utf8=%E2%9C%93&q=is%3Apr+%22update+is+not+a+fast+forward%22+

From what little I've read, I see other projects having similar problems, and some people concluding that the GitHub API can take a while to update (up to 30 seconds?) due to caching. I'm not too familiar with how homu works, but maybe a longer retry might help?

It turns out that there is a known artist for the Hommando art: https://www.pixiv.net/en/artworks/19351345

Could we credit the artist? 😁

Reviewing a PR with an approve comment and writing "@bors: r+" in it does not trigger any actions. See: rust-lang/libc#1526 (comment)

I recently issued the command @bors r+ rollup+, because I have seen plenty of cases where one has to add a + after a command to make it happen. Not so for rollup, it seems, but bors also did not complain. Can we get error messages when there is a word+ or word- but bors does not actually recognize this as a command?

Recently I had several cases where a PR started having conflicts with master, but homu failed to report that. Most recently, this happened in rust-lang/rust#71946.

This used to work more reliably, and it is quite useful as otherwise I as PR author have no idea that a rebase is needed.

Should check if this function is implemented correctly:

See e.g. rust-lang/rust#61569 (comment).

See e.g. https://github.com/rust-lang/rust/issues?q=label%3Arollup+is%3Aclosed

We'll need to do it manually on beta rollups tho.

Doing bors r- retry (e.g. because we realized a PR would fail but is already being tested, so we want it to be removed from the queue and the active job to be stopped) leaves the PR with incorrect labels: the PR is still labeled "waiting for bors". This also happen when first doing "bors r-" and then in another comment doing "bors retry". See rust-lang/rust#66995 (comment) for an example.

I guess "bors retry" fails to detect that the PR is not actually queued any more, and thus incorrectly sets the "waiting for bors" label.

If we switch to Azure Pipelines for rustc we're going to have two pipelines, one for try builds and one for auto builds, and homu doesn't support having different check names at the moment. We need to add that.

On this crates.io PR (and not any other PRs today), the homu checks have timed out multiple times, even though the auto branch has built successfully in travis.

1. I have no idea what's going wrong
2. I don't see anything in the homu commands that will cancel this situation?

Similar to rust-lang/highfive#131.

When you make rollups, a branch named rollup is created for you. This usually works well. However, sometimes I want to do some planning of several rollups in sequence. Then the interface doesn't work so well because if you already have a rollup branch available, it will force-push to that one killing your already in-progress rollup PR.

Instead, it would be good if I could assign a name to the rollup PR myself, e.g. rollup_alpha and rollup_beta, using an input textbox.

Additionally, I think it would be nice if the default behavior were to generate a unique name for that rollup in the input box (can be done client side or server side... not so important). The rare use case of force-pushing to an existing branch can still be supported by changing the name yourself to rollup.

cc @pietroalbini

Oftentimes reviewers will write something like r=me with green travis.
It would be good to automate this sort of thing such that a reviewer can write:

@bors r=me

and then bors will r+ once travis is actually green.
That way, you don't need any other reviewer to intervene or to delegate bors privileges.

There is another edge case in homu command handling: when an user replies to a comment via email by default the parent command is quoted, and the old parser code tried to handle it. We should ignore commands when the line starts with >, to hopefully catch quoted emails, or if the new parser already handles this a test should be added.

Example: rust-lang/rust#61540 (comment)

I put a @bors r+ inside a PR-approval and the bors-action was not triggered by it.

The typical workflow when having to get perf data for a commit is

@bors try

(wait until bors posts that it is done)

@rust-timer build SHA

(wait until that is done)

It would be great if bors would have a command like perf, that would work basically exactly the same as try, except that the "try build done" message would invoke the rust-timer bot the same way that we currently have to do manually (yay, bots calling bots). So, no human interaction should be needed, after doing @bors perf, until the final perf results are in.

Cc @Mark-Simulacrum

Currently, once a pull request has been approved r+, it can not be tried.

There are times when we want to do a timer run, even after r+ing the merge request, so it would be great if we could still @bors try after approval.

cc @Centril

This is very similar to #80: just like unapproved PRs should not be in a rollup, the same goes for "rollup=never" PRs. So maybe it would make sense to likewise block them?

Cc @pietroalbini

See rust-lang/rust#62010 (comment).

cc @kennytm

PR rust-lang/rust#66431 was merged as part of a rollup. After the merge, bors commented that the PR was 'made unmergeable' due to the rollup PR. This is a pretty useless message, since a merged PR is intrinsically unmergeable.

There are no docs here about which commands @bors supports, how to use it, etc.

When editing a GH comment that contains a @bors command, the command gets re-evaluated. This is confusing when it is a bors r+ (as bors complains about double-approval) and can cost a lot of CI time when it is a bors retry.

IMO it would be much less surprising if bors ignored edit events, and only considered new comments.

In some cases, a PR goes through bors as a matter of process but doesn't actually need any review -- for example this miri PR. In that case it would be nice if we could just have a bors command in the PR description, instead of having to submit the PR and then add a comment with the comment.

Seeing this is not very informative when #N is a rollup PR:

The latest upstream changes (presumably #N) made this pull request unmergeable. Please resolve the merge conflicts.

Assuming there is a way to get the list of files in the diff without getting the whole diff, from the github API (or maybe the diffs are cheap?), it might be possible to quickly check, for rollup PRs, which of the rolled-up PRs had any of the files that now conflict.

Right now, reviewers have the option to rollup a PR which notifiers the roller-upper (e.g. @Centril or @Manishearth) that this PR is ~always safe to include into a rollup PR.

However, this is a rather blunt instrument. There are a bunch of other PRs that I will attempt to include into a rollup that are not @bors rolluped.

There are also PRs that should never be included into a rollup. It would be nice to get such a notification in the queue interface. E.g. @bors never-rollup. These PRs should probably get p=1 if no higher prio is assigned. To make this visible in the homu web interface, a new column could be added at the end. Otherwise, you could color the rollup-intention with:

• green: always rollup
• nothing: maybe rollup
• red: never rollup

(or other colors...)

We should eventually automate rollups, with failures pinging humans.

Steps:

• Add rollup levels (#22)
• Add travis status indicators to the list view (#26)
• Add a subsystem that picks a bag of approved non-never-rollup PRs, balancing travis-pass rollup=always and rollup=maybe counts based on some heuristics

When I push to a PR that was r+'d, bors immediately removes it from the queue (looking at https://buildbot2.rust-lang.org/homu/queue/rust). However, the label in the respective PR still says "waiting-on-bors". It should get updated as well.

E.g. in rust-lang/rust#61059 (comment), I wrote:

@bors try

after a failing try build.

But it didn't work; but it should... I would forget to write @bors retry =)

The UI for rust-lang/rust frequently fills up with numerous "success" at the top of the page.

There's sort of two bugs here. First, we don't currently keep whether a build is try or r+ in the DB, AFAICT, which means that these aren't displayed as success (try) after bors reboots.

The easy fix here is to just never show successful builds -- I'm not sure that they are important enough to be so prominent in the UI, since there's nothing that can really be done with them.

GitHub announced draft PRs as a native WIP label for pull requests, and it would be great to support it on bors.

Blocked on sigmavirus24/github3.py#926.

Prevent situations like rust-lang/rust#50686 (comment)

We had to restart the production homu instance while the tree was closed, and once we restarted it the web UI raised this exception:

Traceback (most recent call last):                                                                                              
  File "/usr/local/bin/bottle.py", line 862, in _handle                                                                         
    return route.call(**args)                                                                                                   
  File "/usr/local/bin/bottle.py", line 1742, in wrapper                                                                        
    rv = callback(*a, **ka)                                                                                                     
  File "/homu/homu/server.py", line 75, in index                                                                                
    for label in sorted(g.repos)])                                                                                              
  File "/usr/local/lib/python3.6/dist-packages/jinja2/asyncsupport.py", line 76, in render                                      
    return original_render(self, *args, **kwargs)                                                                               
  File "/usr/local/lib/python3.6/dist-packages/jinja2/environment.py", line 1008, in render                                     
    return self.environment.handle_exception(exc_info, True)                                                                    
  File "/usr/local/lib/python3.6/dist-packages/jinja2/environment.py", line 780, in handle_exception                            
    reraise(exc_type, exc_value, tb)                                                                                            
  File "/usr/local/lib/python3.6/dist-packages/jinja2/_compat.py", line 37, in reraise                                          
    raise value.with_traceback(tb)                                                                                              
  File "/homu/homu/html/index.html", line 26, in top-level template code                                                        
    <li><a href="queue/{{repo.repo_label}}">{{repo.repo_label}}</a> {% if repo.treeclosed >= 0 %} [TREE CLOSED] {% endif %}</li>
jinja2.exceptions.UndefinedError: 'github3.repos.repo.Repository object' has no attribute 'treeclosed'                          

To "fix" the issue I had to reopen the tree and then restart homu again. We should properly fix this.

People need to be able to r- their own PRs.

Use case:

I make a PR that updates clippy.
The PR is r+ed and prioritized.
In the meantime another rollup merges and breaks clippy again.
Now the clippy-pr needs to be updated again to a working version of clippy since it won't pass CI otherwise but I cannot prevent it from being tested and potentially waste 3 hours of CI time since I cannot r- PRs I authored.

rust-lang/rust#61298 (comment)

Hello

I find the git fixup commits quite useful.

For those who are not used to them, this is how it works:

• I create a pull request.
• There are some nitpicks in the review.
• The nitpicks don't deserve a full commit to fix. But I also don't want to rebase the branch during the review, as that makes reviewing a bit harder. I want to just push a little commit with the fixes. This can be created by git commit -a --fixup=THE-COMMIT-TO-BE-FIXED.
• After the whole review is concluded, I do git rebase --interactive --autosquash THE-BRANCH_COMMIT. This'll squash the fixup commits into the commits they fix up. Note that this doesn't necessarily squash the whole branch into one commit.

However, such flow seems to be advanced and @bors/homu doesn't know about it. Which leads to two disadvantages:

• There's another round with the reviewer (they have to tell me it is time to do the rebase).
• It can happen by accident that a branch with fixups gets approved (rust-lang/rust#61421).

I was thinking if there's a way to improve the support for this (and make the flow more known, because I believe it has advantages). I wonder about three different options:

• The bot could refuse to proceed if a fixup message is present in the branch with an explanation message, handling the second point.
• The bot could refuse to proceed, but remember the approval. If the rebased branch is pushed and has empty diff against the not squashed, it could remember the approval and proceed then (but I don't know, this may be hard to implement).
• The bot could actually perform the rebase. But I'm not sure this is desirable (because then it loses eg. gpg signatures on the commit) and there could be conflicts to resolve during the rebase.

What do you think?

Re-rollups (rolling up with a very similar set of PRs, because one of them failed or so) are currently quite painful. It would be great to get better support from bors for that.

@pietroalbini had a great idea for this that does not require extra server-side state:

add a "Create a similar rollup" link in the rollup PR body, with the link going to https://bors.rust-lang.org/queue/rust?prs=12345,6583,342345

Now that rust-lang uses Azure pipelines exclusively, the "Testing commit ..." message of bors could link the Azure pipeline of the test.

Also, currently, when looking at the queue and clicking on a PR that's currently being tested, the pipeline of the test is not linked there either.

Part of #25

Would be nice if the PR list view could show the various status checks that show up at the bottom of the PR for approved PRs. We should use the GH status hook (which we already use) to store status check results for every PR.

This would make rollups much easier: Pick every travis-pass PR that is rollup=always, pick some rollup=maybe, and no rollup=never.