Life as a GSoC student: What I learned about open source development through Probot

Abhijeet Pratap Singh is a student at the Indian Institute of Information Technology in Tiruchirappalli, India. He was selected to be one of the Google Summer of Code (GSoC) students for the Probot project. In this post, Abhijeet recounts his experience working with the Probot Team at GitHub and what he learned about working with other developers on an open source project.

This spring, I was selected to participate in Google Summer of Code (GSoC), a program that pairs student developers with open source projects. I was placed with the Probot Team at GitHub. Probot is an open source framework used to build applications for GitHub based on NodeJS. These applications improve and automate your workflow while working on GitHub.

Getting started with Probot

I’m a Computer Science and Engineering undergraduate at the Indian Institute of Information Technology. When I entered the Institute, I was very interested in knowing more about software. I explored different opportunities and found out about GSoC through Quora earlier this year.

I learned about Probot while researching the different projects partnering with GSoC. I had some previous experience working with bots and NodeJS and decided to try out applications built with Probot. I found the Probot community, a Slack community of developers who use Probot, which pointed me to the Probot Summer of Code and Probot’s GSoC project ideas. The project idea list helped me identify what project I should submit a proposal for.

I initially focused on the Twitter integration proposed in Probot’s ideas repo. After a few days of tinkering, I successfully developed my first Twitter integration bot. I recorded a screencast to log my progress with the bot and shared it with Brandon Keepers (@bkeepers), Jason Etcovitch (@JasonEtco), and Gregor Martynus (@gr2m).

I later submitted proposals for the Twitter integration and Weekly Digest projects when the student application period started. My proposal for the Weekly Digest project was accepted, and I became the Student Developer for Probot. The results were announced on April 23. I was so happy to see that my project was accepted and was really excited for this summer. Gregor Martynus (@gr2m) and Wilhelm Klopp (@wilhelmklopp) were assigned as my mentors.

Working on the Weekly Digest project

GSoC kicked off in late April, and I spent more time exploring the community and its best practices. I also met my mentors over video conference. We discussed a plan to move forward with and implement our projects. Then we created the Weekly Digest repository in order to track progress.

The coding round began in mid May. I started by opening a few issues and pull requests, making some commits, and exploring GitHub’s REST API and GitHub’s REST API client for NodeJS. My mentors and I met weekly to go over the work I did and help out whenever I got stuck. It was a great way to discuss best practices, standards, and tools that developers use.

After working on the project, I got very close to a pre-release version of the app and released an alpha version of the Weekly Digest.

Here’s a GIF of the Weekly Digest app in action:

The Weekly Digest provides an overview of activity in your repositories

How the Weekly Digest app works

When you install the Weekly Digest in your (or your organization’s) repository, it curates the following data and publishes it as an issue:

  • Issues created in the last week
    • Opened issues
    • Closed issues
    • Noisy issues
    • Liked issues
  • Pull requests opened, updated, or merged in the last week
    • Opened pull requests
    • Updated pull requests
    • Merged pull requests
  • Commits made in the master branch in the last week
  • Contributors adding contributions in the last week
  • Stargazers, or the fans of your repositories, who really loved your repo
  • Releases of the project you’re working on

The app, as the name suggests, generates these digests and publishes them on a weekly basis, typically on a Sunday. You can change the default configuration of the app by adding a .github/weekly-digest.yml file in your GitHub repository, which allows you to configure the publish date and the specific information included in the digest.

Install the Weekly Digest app

What I gained from this experience

Becoming a software developer has been my dream ever since I was a kid. My mentors were happy to answer all of my questions and took time out of their busy schedules to meet with me. Through GSoC, I learned how a project is maintained and how developers work together to deliver solutions. And I got to develop a love for open source through my work with Probot!

I was really lucky to be guided by my mentors, Gregor Martynus (@gr2m) and Wilhelm Klopp (@wilhelmklopp). Special thanks to them, Brandon Keepers (@bkeepers), Jason Etcovitch (@JasonEtco), and the awesome Probot community for accepting me as a Student Developer for this year’s GSoC!

Learn more about Probot

Release Radar · July 2018

Release Radar July 2018 Edition

July has come and gone, leaving a lot of exciting releases in its wake! It’s been an especially big month for people learning to program—we’re highlighting two releases that will help new programmers—but there’s something for everyone in this month’s Release Radar.

raylib 2.0

raylib is a games library designed to help people learn to make games without a large environment and tailored tools. raylib 2.0 has removed all external dependencies, increased the number of supported platforms (including BSD, Linux, and 64-bit Android), and updated the included templates and examples. Scope out the raylib 2.0 release announcement to learn more.

raylib 2.0 demo

Did you know? raylib started as a weekend project, so Ray could help young people learn game development.

Mu 1.0

Mu is an IDE for teaching and learning Python and embedded programming. It’s designed for beginners, but anyone can use it—and with its latest release, Mu is joining the 1.0 club! Mu 1.0 improves the user interface and makes it more consistent across platforms, adds better support for line endings and encodings, and translates the app to more languages, including Spanish, Japanese, and French. Check out the Mu changelog for details.

Mu’s PyGameZero mode

Did you know? Mu comes bundled with a bunch of libraries, like PyGame and Matplotlib. Learning to program doesn’t need to mean learning dependency management at the same time.

ALE 2.0

ALE is the Asynchronous Lint Engine for Vim and NeoVim. The plugin provides as-you-type static analysis on your code and works with linters like ESLint and autopep8. ALE 2.0 improves the way ALE connects to servers, adds support for new linters and formatters, and fixes some bugs. See the ALE 2.0 release notes for details.

Did you know? ALE uses the Language Server Protocol which simplifies connecting editors and IDEs to language-specific tools.

Pico 2.0

Pico is a lightweight, database-free content management system. It helps you turn markdown-formatted content into the pages of your site. The latest release, version 2.0, moves configuration from PHP files to YAML, introduces new features for theme developers, and helps plugin authors and users with distribution and installation. There are some breaking changes though, so check out the Pico upgrade guide, which also goes in-depth on the project’s latest developments, before you dive in.

Did you know? In the International System of Units, the prefix pico denotes 10−12, or one trillionth. Pico, in other words, means small—really small.

Helpy 2.0

Helpy is a helpdesk web application with ticketing, community forums, a knowledgebase, and more, so your customers can get help from you and each other. The project is celebrating its 2.0 release, unveiling a new admin user interface, a new theme, and changes for compliance with GDPR. Take a look at the Helpy 2.0 release on GitHub for more info.

Reactotron 2.0

Reactotron is a multiplatform app for inspecting your React and React Native applications. Reactotron helps you look into the state of your application, benchmark performance, and more. The latest release, version 2.0, adds support for multiple devices, a new user interface, and bug fixes. Check out the Reactotron 2.0 release on GitHub for more information.

Apollo 3.0

Apollo is a platform for developing autonomous driving. The project’s roadmap aims to obviate the need for actual roadmaps by supporting fully self-driving cars. Apollo 3.0 introduces new features such as the Guardian safety module and the Apollo Sensor Unit that provide interfaces to many types of sensors like cameras and radar. This release aims to support level 4 autonomy, so that a vehicle can operate without a human driver in defined conditions and locations. Take a look at the Apollo 3.0 release notes to find out more.

Did you know? You don’t need a self-driving car to test out Apollo. There’s a simulator for that.

Ora 3.0

Ora is a terminal spinner. You can use Ora to show your users that something is happening while they wait on your Node.js command-line program. Use one of dozens of premade spinner animations, or define your own. Ora 3.0 fixes bugs and drops support for Node.js older than version 6. Read the Ora 3.0 release notes for details.

Ora 3.0 spinner examples

Xenko 3.0

Xenko is a game engine used to create everyything from 2D games to VR experiences for multiple platforms. And as of the latest 3.0 release, it’s now free and open source. With it’s impressive list of integrated editors plus PBR materials, light probes, post effects, and next generation graphics APIs, you might want to take it for a spin on your next project or game jam.

Xenko 3.0 screenshot

If you’d like to contribute, pull requests—and financial contributions via Xenko’s Patreon—are welcome.

That’s just a handful of releases you shipped last month—keep them coming! If you’ve got a release that should be on our radar, send us a note.

Tutorial: How to deploy an app to production with an actual button

If you’re familiar with the deployment process, chances are you’re familiar with the set of repeated steps that have to be completed before you push to production. It’s not a process that would be described as “fun”, but it’s an important one nonetheless.

But what if we could deploy and release an application with the push of a real button? In this post, we’ll go over how to make your own “ship it” button to deploy a new release.

Ship it GIF


To follow along with this tutorial, you’ll need:

  1. An AWS IoT Dash button: To jumpstart, we’re going to use a premade IoT button that you can purchase on Amazon.
  2. An AWS account: Create an AWS account. You’ll need to create one even if you have an account. We’ll be using the AWS Lambda tool to call the GitHub API.

    Note: This service charges you for the data you use. You can also use a virtual dash button service from your mobile phone. And the code from our guide can be connected to any application—not just AWS.

  3. To set up your development environment: We’ll be using Node.js 6.10 when connecting with AWS Lambda. Download the latest node version—or just use Lambda for the development.
  4. A GitHub account: Create a GitHub account. It’s fast, easy, and of course, free.
  5. A GitHub API access token: A personal access token allows you to authenticate who you are when using GitHub through the API or otherwise programmatically. To generate one:

    • Navigate to
    • Click Generate new token
    • Select the scopes we’ll be using for the tutorial: repo_ deployment, write:packages, read:package

Once you’ve finished setting up all of the prerequisites, get started with the rest of the setup process.

Step 1: Writing the GitHub API calls

Use Node.js to call the GitHub API and the Octokit/rest.js library to wrap API calls. Octokit works like any other library and uses the GitHub REST API endpoints—but it also allows us to use await, async, promise, and callback wrappers all contained. Plus, we can authenticate at the beginning, then perform our calls.

Let’s take a look at the index.js file we’ll create.

Step 1a: Setting up Octokit

At the top of the file, we require our Octokit npm package:

const octokit = require('@octokit/rest')()

Step 1b: Authenticating

Then we authenticate with GitHub using our newly created personal access token:

       type: 'token',
       token: process.env.GH_TOKEN

Step 1c: Setting up the event handler

To use AWS Lambda, we need a handler to understand what to do when the button is clicked. We add the wrapper:

exports.handler = (event, context, callback) => {
  console.log(`Received event: ${event}`)
  let tag_name
  const owner = process.env.GH_LOGIN
  const repo = process.env.GH_REPO

Step 1d: Retrieving and creating the latest release

Inside the exports.handler function, you’ll find releases. The GitHub Releases API is a hidden gem housed under the Repository API. You can create a draft, prerelease, set up the branch to release from, and more from one API call.

For this scenario we’ll get the latest release and increment it by one. Then we’ll publish a new release each time the button is clicked.

Both of the methods below are Promises and will create a new release once the latest release has been retrieved. To do so, we need our GitHub username, the repo we want to release to, and a tag_name when creating it. There are several optional details we can add, but here are the basics:

    }).then(result => {
    tag_name = (parseInt( + 1.0).toString() + '.0'

      }, (error, result) => {
        if (error) throw new Error()
        if (result) console.log(`Created Release: ${JSON.stringify(result)}`)

Step 1e: Creating a deployment

In addition to creating a release, we’re going to start a deployment by calling upon the GitHub Deployments API. We can do this by specifying the login, repo, branch we want to deploy from, and optionally, a description:

      ref: 'master',
      description: `Deploying ${tag_name} version`
    }, (error, result) => {
      if (error) throw new Error()
      if (result) console.log(`Created Deployment: ${JSON.stringify(result)}`)

Once the release and deployment methods are inside the event handler, the code is almost set. We’re using Node.js, so make sure to run npm init and npm install @octokit/rest to ensure the environment is setup.

A repository has been created with the entire setup process and you can find the link in Step 3 when we need to call on the code. To actually run the code, let’s first configure the new AWS IoT button.

Step 2: Configuring the AWS IoT button

To set up the button, follow the AWS quickstart guide or download the AWS IoT Button Dev app, available on iOS or Android.

Once your button is configured with WiFi, feel free to test out the example lambda functions like sending a text or email. Next we’ll create a new function.

Step 3: Setting up an AWS Lambda function

Once we set up our lambda function, we’re ready to release! Navigate to the AWS Lambda Function Console.

Step 3a: Creating the function

In orange, you’ll see a “Create Function” button, whether you’re viewing your dashboard or functions. Below are detailed steps to walk through the process. If you get stuck, try watching this video walkthrough.

  • Click Create Function and Author from Scratch.
  • Enter a “Name”.
  • Ensure the runtime is Node.js 6.10.
  • Under “Role”, select Create new role from template(s).
  • Enter a “Role Name”. It can be the same as “Name”.
  • Under “Policy Templates”, select AWS IoT Permissions.

Step 3b: Adding the button trigger

Once your function is created, you’ll see it has a number of different settings we can configure. We’ll edit the “Designer”, “Function Code”, and “Environment Variables” aspects of the function. Let’s begin with “Designer”.

  • Add the AWS IoT Trigger in “Designer”. The “Configure Triggers” box should appear.
  • Select IoT Button as the IoT Type.
  • Enter the Device Serial Number located on the back of the button.
  • Make sure to check Enable the Trigger, then click Add.

Step 3c: Uploading the code

Now that we have set up the button trigger, we need to make sure the code is correct. We’ll take the code from Step 2 and upload the zip file.

If you would like to use the code you wrote earlier, zip the package to the root of the folder with zip -r ./* or you’ll receive a cannot find /index.js error. Otherwise, clone the contents of the repository with git clone Make sure the file is cloned with the contents.

Once you have your zip file:

  • Reveal the “Function Code” box by pressing the “Function Name” box in “Designer”.
  • Scroll to “Function Code”.
  • Under “Code Entry Type” select Upload a .zip file.
  • Once you upload your file, click Save. You should now have the ability to “Edit Code Inline”.

Step 3d: Adding in the environment variables

  • Scroll to “Environment Variables”.
  • Create GH_LOGIN, GH_REPO, and GH_TOKEN for your environment variables and add your login, the repository you want to release to, and the personal access token you created in the prerequisites.

Step 3e: Test

Now we’re ready to test our button with the following steps:

  • Click Test, a button that pops up with a “Configure Test Event”.
  • Select the Hello World Event Template (Default).
  • Enter in an “Event Name”.
  • Click Create.

When you click Test you should be able to see new releases on your repository as they are created and the logs with Created Deployment and Created Release. Note: The release will only work if there is already a release present in a number format (1.0, for example).

You can check to see if your new release was created at your repositoryURL/release. Check the logs to make sure no errors were thrown. If you are seeing {message: not found} or {message: bad credentials} check your Personal Access Token permissions.

Step 4: Clicking the button

Now return to the “Configure Trigger Stage” and make sure your button is set. You should be able to click the button and get the same results you got when you tested it.

Next we’ll go into more detail on how to incorporate the GitHub events you just triggered within different workflows.

Step 5 (optional): Integrating within your workflow

Clicking the button will trigger a release and deployment—but what do you do with this information? At this point, you can configure it to your workflow or deployment process. The diagram below outlines how to communicate between the button or “Tooling”, GitHub, and our server.

+---------+             +--------+            +-----------+        +-------------+
| Tooling |             | GitHub |            | 3rd Party |        | Your Server |
+---------+             +--------+            +-----------+        +-------------+
     |                      |                       |                     |
     |  Create Deployment   |                       |                     |
     |--------------------->|                       |                     |
     |                      |                       |                     |
     |  Deployment Created  |                       |                     |
     |<---------------------|                       |                     |
     |                      |                       |                     |
     |                      |   Deployment Event    |                     |
     |                      |---------------------->|                     |
     |                      |                       |     SSH+Deploys     |
     |                      |                       |-------------------->|
     |                      |                       |                     |
     |                      |   Deployment Status   |                     |
     |                      |<----------------------|                     |
     |                      |                       |                     |
     |                      |                       |   Deploy Completed  |
     |                      |                       |<--------------------|
     |                      |                       |                     |
     |                      |   Deployment Status   |                     |
     |                      |<----------------------|                     |
     |                      |                       |                     |

There are several deployment services and providers to choose from. At GitHub we use Heaven to deploy directly with our chat bot, Hubot. Some companies have even adapted it into their flow. There are also applications in GitHub Marketplace that specifically help developers with fast and easy deployment.

In order to deploy an application, we use Probot, a tool for creating GitHub Apps and automating your workflow in a quick and easy way. In this case, it acts as a third party to listen for deployment events and send back deployment statuses by creating issues.

Step 5a (optional): Homemade deployment server with Probot

The application is based on the GitHub delivering deployments guide but modified to Node.js in order to use Probot.

In this scenario, the bot listens for particular GitHub events, meaning when someone presses the button to create a deployment, the application knows to create and push the new build—and provide a deployment status. The button deploys to Heroku—their Build and Release API allows us to push the GitHub release package and deploy instantly from a single POST request.

If you want to take a look or try it yourself, learn more in the Deployment Status Bot repository.


While you might not physically click a button to deploy your application to production regularly, you can always trigger these GitHub events to mix up a repetitive deployment process.

If you need any additional resources or help, feel free to go through the Building a GitHub App quickstart guide. Or sign up for the GitHub Developer Program, and post on the GitHub Platform Forum.

Updates to protected branches

Protected branches make sure the right reviews happen, support passing CI, and prevent force pushes. With our latest update, you can automatically enforce protected branch settings across multiple branches in your repository.

If you’re a repository owner or have admin permissions in a repository, you can now customize branch protections and enforce certain workflows, such as requiring more than one pull request review or requiring certain status checks to pass before allowing a pull request to merge.

Update your branch settings in the "Branches" tab of your Settings Page

Branch protection rules

Branch protection rules build on our existing branch protection functionality. Instead of setting up individual protections for multiple branches, you can share the same set of protections across different branches matching the same naming pattern.

Branch protection rule patterns are based on fnmatch syntax. You could use releases/v?.? to automatically protect branches like releases/v1.0, releases/v2.0, and releases/v2.1. And [1-9]-[0-9]-stable could automatically protect branches like 1-0-stable, 2-0-stable, and 2-1-stable.

View more fnmatch documentation or learn more about configuring protected branches.

Linked repositories for organization-owned project boards

Managing your projects at the organization level just got easier. When creating or viewing an organization’s project board, you can now specify which repositories are most relevant to the project you’re working on. This new feature makes search faster and more relevant by automatically scoping it to your linked repositories.

Link repositories to your projects board for easier, more relevant search options

Link to relevant repositories any time you create a new organization-owned project board—or while actively managing a project. As you manage a project, you can change and add up to five repositories where the work being done for your board can be referenced.

Linked repositories will appear on the project board list, making it easier to find your board and understand, at a glance, where work is happening within your organization.

Learn more about linking repositories to organization project boards



GitHub Universe logo

GitHub Universe

October 16-17 in San Francisco
Get tickets today

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more