GitHub bots for managing issues

@sashko - we’re* working on a bot-engine for Material-UI. It listens for github webhooks, and takes configuration as code that can be as simple as:

  {
    description: 'Label new issue as "Triage"',
    event: 'issues',
    conditions: { 'action': 'opened' },
    requests: {
      method: 'POST',
      path: '/repos/:owner/:repo/issues/:number/labels',
      body: ['Triage']
    }
  },

Or as sophisticated as:

{
    description: 'Mark pull requests with merge conflicts as "PR: Needs Rebase" when master is updated',
    event: 'push',
    conditions: {
      'ref': 'refs/heads/master'
    },
    requests: (eventObj, githubRequest) => {
      const fullName = eventObj.payload.repository.full_name;
      return new Promise(resolve => setTimeout(() => resolve(), 5000))
        .then(() => githubRequest({
          path: '/search/issues',
          payload: eventObj.payload,
          query: {
            q: [
              `repo:${fullName}`,
              'is:open',
              'type:pr',
              '-label:"PR: Needs Rebase"'
            ].join(' ')
          }
        }))
        .then(response => response && response.items ? response.items : [])
        .then(pullRequests => Promise.all(
          pullRequests.map(pr => (
            githubRequest({
              path: `/repos/${fullName}/pulls/${pr.number}`
            })
          ))
        ))
        .then(pullRequests => pullRequests.filter(pr => pr.mergeable === false))
        .then(pullRequests => Promise.all(
          pullRequests.map(pr => (
            githubRequest({
              method: 'POST',
              path: `/repos/${fullName}/issues/${pr.number}/labels`,
              body: ['PR: Needs Rebase']
            })
          ))
        ));
    }
  }

The nice thing about this is you have complete flexibility to do anything the github API supports.

It’s getting there, but slowly - everyone who works on Material-UI core team (and that’s only a handful of us) does so on their own time, and this project is lower down the priority stack, but it’s getting there.

I’ll post back when we go live and the code & docs are in a publicly usable state.

Edit: When I say ‘we’, the original concept was mine, but @nathanmarks has done all the hard work. :slight_smile:

1 Like

Please do! I’d kill for better bots. I bet @zoltan would as well!

This is something I’ve been thinking a lot about recently too. The best looking tool I’ve seen is Haunt from the Bootstrap team. The troubling thing is it’s unmaintained and looks like it wasn’t successfully implemented for bootstrap. I tried finding a better, maintained bot along with a project that uses one effectively and I couldn’t really find anything compelling. This has given me pause on whether it’s a good idea to begin with.

Have you experimented with being a human version of your planned bot for a while and see what sort of effect it has? That was going to be my next move.

2 Likes

Yes, I am MattBot. :smile:

We apply the labels that we are going to use the bot for pretty religiously:

‘PR: Needs review’ (New PR, or code has been updated)
‘PR: Needs revision’ (Issues / suggestions with the code)
‘PR: Needs rebase’
‘PR: review accepted’ (Needs final review, squash and merge)
‘triage’ (New issue)

As well as having introduced an issue template, and a PR template requesting certain conventions for PR & commit descriptions.

It’s quite a task to keep them up-to-date, and we find ourselves doing a pass over open commits to make check if something has changed that requires a label to be updated to flag that a PR (or to a lesser extent an issue) needs attention.

We’re going to start slowly with introducing automation for this, but fully intend to automate anything that can be over time.

Sorry, meant to circle back on this much sooner!

We went live with the first release of mii-bot, and it’s been chugging along ever since! You can see it in action on the Material-UI repo: https://github.com/callemall/material-ui/pull/4902

Development on the bot and new rules has taken a bit of a back seat due to a complete rewrite of Material-UI, but it is most definitely not abandoned, and it has scope to do lots more with additional configuration rules - the engine is essentially done. The one thing a bit lacking is documentation, but it should be easy enough to figure out from the code (or just ask :slight_smile:) : https://github.com/muibotdev/muibot

1 Like

Kudos on all the Material UI work, btw. MaterialUI + React + Meteor has been a dream solution.

It’s very much a community and team effort, but coming from an authority such as you, that’s quite the complement. :blush: Thank you!

Even better things to come in the next branch.

I agree with you on the Meteor / React / Material-UI trifecta though! :slight_smile:

Just as an FYI, we’re migrating all of the FHIR resources in the Clinical Meteor branch to React + Material UI components. Very much following your lead in this new UI layer.

Assuming a CRUD pattern for each FHIR resource, and 100 resources, that will wind up being about 400 cards. At some point, we’re going to pull all the clinical:hl7-resource-* packages into one NPM repo that mimics the material-ui repo. We’ll call it material-fhir-ui or something. (It’s basically the evolved version of the glass-ui and photonic subprojects.)

Mind if I reach out to you sometime? I’d be interested to learn a bit more about the details of the muibot, your testing infrastructure, build pipeline, etc.

Nathan Marks is probably the best person to chat with about the bot, since he pretty much wrote the whole thing in the end! You could try pinging him in gitter, but it might actually be quite useful to have that discussion in a github issue in the mui-bot repo, as a proxy for documenting some of those things. :slight_smile:

He would also be able to give you a more complete picture on the Material-UI testing infrastructure as he joined the team on a testing mandate, and made many of the changes in that area to enable us to actually start writing tests. Test coverage was almost non-existent before! The next branch adds visual regression testing.

As for the build pipeline - there’s not much to it really, we run babel with a fairly minimal config on the src dir, output to a build dir, then run a script to create new package.json by pulling the relevant fields from the material-ui repo package.json, and to copy the README etc, then publish to npm from the build directory.

This leaves a clean-and-lean published library, that doesn’t make too many assumptions about the build tools and process of the applications that consume it.

If you’re embarking on a big migration to Material-UI, it might be worth considering what the impact of next will be. In some areas (for example Table) it’s a complete rewrite with new component structure & many API changes, but more features and less bugs! Others won’t be so drastically affected, but pretty much every component is going to change to some extent since the styling API is the core change, and with API standardization meaning things like callback parameter order changing for components that were doing their own thing.

It’s very much work-in-progress though, with many components still to be migrated, so this is more a heads-up that if you migrate to Material-UI 0.16.x now, you may have a fairly large job to migrate to Material-UI next when it’s finally ready.