Add customizations to config - #3

Request Info app

When a user opens an empty issue or pull request, the Request Info app will do exactly that -- request some more information.

You can see that Request Info has already responded to this pull request with a default message.

Configuration files

Per the app installation instructions, this app requires a .github/config.yml file for it to respond with a default message. I've already included that in this pull request for you. Some apps use these, and some don't use them at all. Some apps might use a .json file, while others might ask you to store configuration settings in a .md file.

This allows you to take default templates and extend them to your own projects.

Step 8: Configure apps

Let's use your default template to learn about APIs. First, make a simple change to the standard message.

⌨️ Activity: Change the default message of your config.yml file

1. Click on the Files changed tab
2. Click the small grey pencil to edit the config.yml file
3. Change the default YAML file message for request app
   - If you aren't sure where to find that, edit the reply on line 6
4. Scroll down and commit your changes

After you update this pull request, look for my comment below

We would appreciate it if you could provide us with more info about this issue/pr!

Nice job!

In the last pull request, we learned about webhooks and how the WIP and Request Info apps only respond to specific events. Webhooks allow you to build or set up GitHub Apps which subscribe to certain events on GitHub. When one of those events is triggered, an HTTP POST payload response is sent to the webhook's configured URL. We saw this with our smee.io webhook.

But webhooks are only one side to this story. To see the other side, meet API endpoints. 👋

API endpoints

API stands for Application Programming Interface. APIs are used to share data or functionality. This is done by making an HTTP request to an API using an endpoint, and then receiving a reponse back.

For example, this is the endpoint to create a new pull request; POST /repos/:owner/:repo/pulls

When an event is triggered, the vastly more detailed GitHub API gives the bot an excessive amount of information (as a payload). The bot takes this payload, alters it slightly, and hands it back to GitHub's API, which delivers the change back to your repository.

Step 9: Learn more about the GitHub API

⌨️ Activity: Discovering endpoints

1. Navigate to this list
2. Find the endpoint that an app would use to create a label on an Issue
3. Post that endpoint as a comment

After you comment, look for my response below

POST /repos/{owner}/{repo}/issues/{issue_number}/labels

Nice try! The label creation endpoint, found here, looks like this: POST /repos/:owner/:repo/labels.

APIs and Webhooks

APIs and Webhooks go hand in hand, but the distinction between them is important.

• Webhooks are specific "noise" interpreters. They listen for specific events to occur as their trigger.
• When an event is triggered, the vastly more detailed GitHub API gives the bot an excessive amount of information (as a payload). The bot takes this payload, alters it slightly, and hands it back to GitHub's API, which delivers the change back to your repository.
• The GitHub API can send information that makes changes to the platform, but only when prompted via webhook.
• The GitHub API and GitHub's webhooks are both key components of GitHub Apps.

Step 10: See your changes in action

Now that you've made the change to your config.yml file, try to trigger that event to see the changes as a user.

⌨️ Activity: Test out your original changes to the config.yml

1. Go open a blank issue to see if the changes you made in your config.yml took effect!