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

Project Management Automation: Support adding milestones for fork PRs. #20058

Merged

Conversation

epiqueras
Copy link
Contributor

Follows #20049.

Separately, there might be alternatives to explore here, where the event is handled in response to the commit as it ends up being pushed to master. In other words, some combination of:

  • The push event
  • Conditioning on commits that occur in the master branch
  • Deriving a pull request associated with the commit
  • Applying milestone to the pull request

@epiqueras epiqueras added [Type] Enhancement A suggestion for improvement. [Package] Project management automation /packages/project-management-automation labels Feb 5, 2020
@epiqueras epiqueras added this to the Gutenberg 7.5 milestone Feb 5, 2020
@epiqueras epiqueras requested a review from aduth February 5, 2020 21:28
@epiqueras epiqueras self-assigned this Feb 5, 2020
.github/workflows/pull-request-automation.yml Outdated Show resolved Hide resolved
@@ -25,8 +25,7 @@ const automations = [
task: ifNotFork( addFirstTimeContributorLabel ),
},
{
event: 'pull_request',
action: 'closed',
event: 'push',
task: ifNotFork( addMilestone ),
Copy link
Member

Choose a reason for hiding this comment

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

Is ifNotFork necessary anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, why wouldn't it be?

Copy link
Member

Choose a reason for hiding this comment

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

It doesn't seem we would ever have a scenario where we would receive a push event and also not immediately bail at the first condition checking the master branch (i.e. I can't see how an error would ever occur if the ifNotFork was not here). I suppose it might still be better to stop it as early as possible to avoid tying it to this specific implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Forks can also have branches named master.

Copy link
Member

Choose a reason for hiding this comment

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

Are we receiving push events for those?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, someone could make a PR from fork/master.

Copy link
Member

@aduth aduth Feb 6, 2020

Choose a reason for hiding this comment

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

Hm, ok. I think I may have been expecting that this condition would somehow already be verifying that the commit happened on wordpress/gutenberg's master, but I see now that's not the case.

But ifNotFork was implemented for pull request events, and I think would need to be updated to support this.

payload.pull_request.head.repo.full_name ===
payload.pull_request.base.repo.full_name

Notably, payload.pull_request doesn't exist for push events.

https://developer.github.com/v3/activity/events/types/#pushevent

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Then it's better to just not use it. I've removed it. No one actually makes PRs from master anyway. We can live without milestones for those edge cases.

Copy link
Member

Choose a reason for hiding this comment

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

Then it's better to just not use it. I've removed it. No one actually makes PRs from master anyway. We can live without milestones for those edge cases.

I don't know how to search for specific examples to share, but I've definitely seen pulls from forked master before. That said, the combination of this and a commit message which matches the (#PR) pattern to get to the point of adding the milestone would be exceedingly rare, yes. And the result would merely be a failing action, nothing too worrisome.

We might want to revisit this in the future to make the logic more durable and to support ifNotFork usage for non-pull_request events (especially given the fact the name is generic enough to easily misinterpret that it ought be supported), but I don't think it's a blocker.

Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

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

@epiqueras
Copy link
Contributor Author

#20058 (comment)

@epiqueras epiqueras merged commit 164d583 into master Feb 6, 2020
@epiqueras epiqueras deleted the add/project-management-automation-milestones-for-fork-prs branch February 6, 2020 10:04
@aduth
Copy link
Member

aduth commented Feb 10, 2020

Small issue with the implementation which causes errors for commits to master: #20144

@epiqueras
Copy link
Contributor Author

Good catch! Fixed: #20147.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Project management automation /packages/project-management-automation [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants