Skip to content
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

Add github-action PR open/closer #1866

Merged
merged 1 commit into from
Dec 8, 2024

Conversation

Mark-Simulacrum
Copy link
Member

@Mark-Simulacrum Mark-Simulacrum commented Dec 8, 2024

This isn't tested, but my hope is that it works ~first try or after small tweaks. I intentionally made it relatively safe (I hope) in terms of not falling into retry loops calling itself, but open to either dropping that or discussing alternatives.

cc @RalfJung

Closes #1864

Sample PR: rust-lang/miri#4081

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.

Left a few comments. Thanks a lot for implementing this!

src/github.rs Show resolved Hide resolved
src/handlers/bot_pull_requests.rs Show resolved Hide resolved

// If it's not the github-actions bot, we don't expect this handler to be needed. Skip the
// event.
if event.sender.login != "github-actions" {
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 this will work, an user with such login doesn't seem to exist? https://github.com/github-actions

I tried to run this on rust-lang/miri#4070:
image

It looks like the login is app/github-actions. Ideally we should also check if it's a bot.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm, I'm not sure if we get is_bot = true in the sender field, I'd have to go look at events we've seen. I've updated to app/github-actions, and we can revisit if this doesn't work in practice IMO.

// Sanity check that our logic above doesn't cause us to act on PRs in a loop, by
// tracking a window of PRs we've acted on. We can probably drop this if we don't see problems
// in the first few days/weeks of deployment.
{
Copy link
Contributor

Choose a reason for hiding this comment

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

I think/hope that this logic should be unnecessary due to the difference between the opened/reopened events.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I missed that those are different - I think I'll go ahead and delete the extra logic since it's not trivial then.

@Kobzol
Copy link
Contributor

Kobzol commented Dec 8, 2024

I tested this locally on my bors-kindergarten repo using gh cli. The PATCH endpoint with just "state=closed" and "state=open" worked, and it has generated a "reopened" event. So looks good to me.

Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

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

Thanks!

@ehuss ehuss merged commit 4e83f7a into rust-lang:master Dec 8, 2024
2 checks passed
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.

Find some way to work around github not running CI on GHA-created PRs
3 participants