Adding Use Case Templates for Workflows

Background

When folks start building Probot Apps, often they already know the kind of thing they want to build. I have identified several patterns in these use cases.

We’d therefore like to enhance our probot/template repository to allow options for different ‘templates’ that represent different use cases for Probot.

Example Usecases

• Base case: adding a label when a new issue is opened

module.exports = app => {
  app.on('issues.opened', async context => {
    // Probot API note: context.issue() => {username: 'hiimbex', repo: 'testing-things', number: 123}
    const issueLabel = context.issue({ labels: ['help wanted'] })
    return context.github.issues.addLabels(issueComment)
  })
}

• Using the Checks API, eg:

module.exports = app => {
  app.on(['check_suite.requested', 'check_run.rerequested'], check)

  async function check (context) {
    // Do stuff
    //  Probot API note: context.repo() => {username: 'hiimbex', repo: 'testing-things'}
    return context.github.checks.create(context.repo({
      name: 'My app!',
      head_branch: pr.head.ref,
      head_sha: pr.head.sha,
      status: 'completed',
      conclusion: 'success',
      completed_at: new Date(),
      output: {
        title: 'My Check',
        summary: 'The check has passed!'
      }
    }))
  }
}

• Using status (?)
  • maybe we would skip this one in favor of urging people to use Checks?
• Using the Git Data API

module.exports = app => {
  app.on('*', check)

  async function check (context) {
    // Probot API note: context.repo() => {username: 'hiimbex', repo: 'testing-things'}
    // Get current reference in Git
    const reference = await context.github.gitdata.getReference(context.repo({ ref: 'heads/master' }))
    // Create a brnach
    const getBranch = await context.github.gitdata.createReference(context.repo({
      ref: `refs/heads/new-branch`,
      sha: reference.data.object.sha // accesses the sha from the heads/master reference we got
    }))
    // create a cne wfile
    const file = await context.github.repos.createFile(context.repo({
      path: 'path/to/your/file.md', // the path to your config file
      message: 'adds config file', // a commit message
      content: 'My new file is awesome!', //the content of your file
      branch: 'new-branch' // the branch name we used when creating a Git reference
    }))
    return await context.github.pullRequests.create(context.repo({
      title: 'Adding my file!', // the title of the PR
      head: 'new-branch', // the branch our chances are on
      base: 'master', // the branch to which you want to merge your changes
      body: 'Adds my new file!', // the body of your PR,
      maintainer_can_modify: true // allows maintainers to edit your app's PR
    }))
  }
}

• Using the Project Cards API
  • code to example to come!

Tests!?!?

Additionally, for each of these usecases, we could add simple test suites for them, since testing is one of our biggest points of friction.

Thoughts, ideas, comments, concerns, etc are all welcome! 💭

cc/ @probot/maintainers

[wilhelmklopp]

⚡️ This is awesome! I love it – I think this will be huge for folks getting started ‼️ All of these would also make for great Glitch blueprints that folks could remix.

Two additional use cases that I think we should consider:

• creating/updating a file based on the diff of a PR after pull_request.opened or pull_request. synchronized (I think this has some overlap with your existing Git Data template)
• creating a deployment status after a deployment event

[bkeepers]

cc @wilhelmklopp @pifafu you may be interested in this based on current projects