gatsbyjs / peril-gatsbyjs Goto Github PK

How best to accurately identify PRs that are related to the issue vs PRs that will fix the issue. Check PR description for fixes or closes?

Ref gatsbyjs/gatsby#8714

I'm going to add all labels from gatsbyjs/gatsby to this one so we can pull them across. Thanks for making this easy, @ZenHubIO!

As previously reported by @DSchau and confirmed by @m-allanson, creating a comment doesn’t always unstale a stale comment correctly.

Example instance is at
gatsbyjs/gatsby#8080

Need to debug this

We already have a travis.yml file here. We should enable travis on this repo to run our unit tests

This is a great first issue for someone!

In the invite-collaborator.ts rule, we want to provide a link to accept the GitHub org invitation:

That line should be edited to say:

2. We just invited you to join the Gatsby organization on GitHub. This will add you to our team of maintainers. Accept the invite by visiting https://github.com/orgs/gatsbyjs/invitation. By joining the team, you’ll be able to label issues, review pull requests, and merge approved pull requests.

This way we don't have to worry about email invites getting swallowed by spam folders, etc. 🎉

We want our changelogs to be useful, so all PRs should merge following the Conventional Commits spec.

Peril should check opened and edited PRs to ensure the title matches the spec.

I don't know if this affects the store per se. But iirc, @gatsbybot would only add a message to a PR when the author's 1st PR opened was merged, if a PR since then had been added and merged, @gatsbybot did not trigger on that PR instead.

It's a minor issue, although did have me confused as I had started contributing in late December and had a couple PRs accepted before my first one was merged 2 or so months after it was initially opened, which is when I got the invitation for swag at the store(I hadn't checked prior).

What about now? cc @piotrkwiecinski @SD10

Recently someone submitted a starter to the site showcase and it got merged. The site showcase is for finished sites with real content, whereas the starter showcase is for unfinished sites with dummy content. Is that the only real difference? Now I realize we probably need to carefully define the difference in our own minds.

Starter that got merged into the site showcase:
https://lisaye.netlify.com/story

PR that merged it:
gatsbyjs/gatsby#7709

See gatsbyjs/gatsby#7379

If all goes well, this should get labeled.

See #4 (comment) and https://github.com/Moya/moya-peril/blob/master/org/aeryn.ts

gatsbyjs/gatsby#11471

It added two questions labels there, we wouldn't want the question label, would we?

ZenHub has a great visual feature to show PRs connected to the issues they will close:

It's not documented, but I think we can give Peril a ZenHub token and let it do this automatically.

Here's what I've been able to infer about how this works.

API URL:

https://api.zenhub.io/v4/repositories/<repo_id>/connection

Required headers:

x-authentication-token: <ZENHUB_API_KEY>

POST body:

issue_number=<issue_number>&connected_repo_id=<repo_id>&connected_issue_number=<pr_number>

• issue_number — this is the issue that will be closed
• connected_repo_id — the repo where these issues live
• connected_issue_number — the PR number

Our Peril task could look at the PR body for the GitHub auto-close keywords (e.g. fixes #XX) and, if they're present, auto-connect the PR to the issue it purports to fix.

Right now our stale messages are a bit formal. Let's make them more playful and friendly.

This ticket is a feature request to account for when Gatsby team members are not available, for instance when they are at a Gatsby Gathering or Gatsby Days.

My idea is that we can configure Gatsbot to notify users when the core team is away. This could be when:

• a user creates a new issue/PR
• a user tags a member of the core team

Gatsbot could comment with some sort of message that says:

• where they are
• when they'll be back
• maybe some 'in the meantime tips', like community guidelines/best practices, and/or a link to spectrum.

Right now, the blog author validation only supports JPG images:

We should actually support all image formats supported by Sharp.

This module supports reading JPEG, PNG, WebP, TIFF, GIF and SVG images.

All that's needed here is to add the allowed file extensions to the validate-yaml.ts section linked above!

Test ?

See gatsbyjs/gatsby#8019

It works on my testing setup: m-allanson/gatsby#38

On 30th Jan I updated the version of Peril that we're running, which fixed some repeating errors and I think was the final thing blocking the 'not stale' rule from working. Need to confirm this.

Is this thing on?

Turns out you can only mention a team if you're a member of an organization. This will be useful for people after they've joined, but not beforehand if they have questions. Remove the mention to avoid confusion.

Adding this so I can reference it in the readme.

There's a great automation that I've seen with Peril where maintainers can comment "merge on green", and Peril/Danger will auto-merge the PR as soon as all checks pass. I imagine this is pretty much a straight copy-paste from any project that supports this behavior, so let's see if we can add it in.

To avoid PRs getting lost, they should be auto-assigned to the person who created it.

I just switched the Peril config over to MongoDB, so I want to ensure that it's still working as expected. This issue will be closed as soon as it's auto-labeled appropriately.

Should point to https://store.gatsbyjs.org

@rally25rs had a great idea in yarnpkg/yarn#7110 (comment) to include a nudge to contribute on older issues.

If we add a sentence or two that keeps Gatsbot's friendly tone and lets people know that the best way to see an issue fixed is to open a PR + link to gatsby.dev/contribute, it may help encourage more contributors (and certainly won't hurt in any case).

Need to fix this

See gatsbyjs/gatsby#11432

In order to post a blog on gatsbyjs.org, authors need to add:

1. A blog post (this one's obvious)
2. Author metadata in https://github.com/gatsbyjs/gatsby/blob/master/docs/blog/author.yaml (this is less obvious)
3. Add a photo to https://github.com/gatsbyjs/gatsby/tree/master/docs/blog/avatars (also not obvious)

To help with this, Peril can parse the frontmatter from the blog post, check author.yaml for a matching author, and validate that the avatar URL matches a real photo.

If anything is missing, Peril can post instructions on how to add the missing info.

As a stretch goal, it would also be nice to add a comment showing the photo and what their author name will be displayed as, just in case someone copy-pasted and forgot to change the author info.

• @pieh has added schema validation for authors.yml (including avatar check)
• Still need check if the author of the blog post exists

This may not be possible, but if we were able to require more strict PR review standards for larger PRs, that would be really powerful.

For example, we could say that all PRs that change less than, say, 20 lines of code can be reviewed and merged by any member of the community, but 20+ line changes require a codeowner to approve.

I have no idea how we'd actually go about doing this; it's just something that came up in conversation and I wanted to capture it for later exploration.