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

Prerequisites

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 Amazon.com 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 https://github.com/settings/tokens
    • 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:

octokit.authenticate({
       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:

    octokit.repos.getLatestRelease({
      owner,
      repo
    }).then(result => {
    tag_name = (parseInt(result.data.tag_name) + 1.0).toString() + '.0'

      octokit.repos.createRelease({
        owner,
        repo,
        tag_name
      }, (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:

    octokit.repos.createDeployment({
      owner,
      repo,
      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 ShipItButton.zip ./* or you’ll receive a cannot find /index.js error. Otherwise, clone the contents of the repository with git clone https://github.com/ani6gup/ShipItButton.git. Make sure the ShipItButtonLambda.zip 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.

Conclusion

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 Classroom report predicts positive student learning outcomes

As of July 2018, GitHub Education has helped over one million students learn to code. Teachers around the world use version control to help students collaborate on software, participate in open source communities, and automate administrative tasks. But what impact does using GitHub have on students? What do students learn by using GitHub?

Education General Manager @mozzadrella and I wanted to find out how using GitHub in the classroom shapes learning outcomes for the 2018 GitHub Education Classroom Report. We surveyed 8,000 students and teachers who had (and had not) used GitHub in the classroom. This post will give an overview and key takeaways.

Read the full report

Overall, we found that how classrooms used GitHub matters—and that students benefited from using GitHub in the classroom in a few important ways. Compared to students who didn’t use GitHub in their courses, students who did:

  • Felt better prepared for their future careers
  • Learned more about industry tools, collaboration, creating a portfolio, and project management
  • Felt more connected to the developer community
  • Felt a greater sense of belonging both in school and in the software industry
  • Benefited more from teacher feedback received on GitHub

screenshot 2018-08-10 14 37 28

What are learning outcomes?

Think of learning outcomes as goals for students. The education field uses these goals to design curriculum and to assess what students know.

In our survey, we focused on these key areas: preparation for the future, classroom experiences, developing a sense of belonging, feedback, and the experience of learning to use GitHub.

Eight thousand students and teachers responded

We compared answers from respondents who used GitHub and those who did not use GitHub in the classroom. Generally, we looked at what the average respondent reported, so the findings may not apply to every classroom.

Positive learning outcomes

Using GitHub (versus not using GitHub) in programming classes predicted greater positive learning outcomes:

  • Students felt more prepared to take part in the developer community: 31% of students who used GitHub in the classroom and 14% of students who didn’t use GitHub in the classroom felt their course prepared them for being a part of the developer community “very much”.
  • Students felt more prepared for creating a portfolio of their work: 30% of students who used GitHub in the classroom and 15% of students who didn’t use GitHub in the classroom felt their course prepared them for developing a portfolio of their own work “very much”.
  • Students felt they learned more about project management: 25% of students who used GitHub in the classroom and 12% of students who didn’t use GitHub in the classroom felt they had learned “very much” about project management.
  • Students felt they learned more about popular industry tools: 29% of students who used GitHub in the classroom and 14% of students who didn’t use GitHub in the classroom felt they had learned “very much” about popular industry tools.
  • Students felt more prepared for future internships or careers: 33% of students who used GitHub in the classroom and 19% of students who didn’t use GitHub in the classroom felt their course prepared them for future internships or careers “very much”.
  • Students felt they learned more about teamwork and collaboration: 32% of students who used GitHub in the classroom and 17% of students who didn’t use GitHub in the classroom felt they had learned “very much” about teamwork and collaboration.

Sense of belonging

Using GitHub (versus not using GitHub) in programming classes predicted a greater sense of belonging, a variable important to academic success:

  • 51% of students who used GitHub in the classroom and 37% of students who didn’t use GitHub in the classroom agreed or strongly agreed with statements indicating feelings of belonging in the classroom.
  • 48% of students who used GitHub in the classroom and 37% of students who didn’t use GitHub in the classroom agreed or strongly agreed with statements indicating feelings of belonging in the field.

Feedback

Of the students who used GitHub in the classroom and received teacher feedback, those who received (versus did not receive) feedback via GitHub benefited more from teacher feedback.

Students felt they used their teachers’ feedback more effectively and found the feedback more helpful:

  • 74% of students who received teacher feedback via GitHub and 67% of students who didn’t receive teacher feedback via GitHub agreed or strongly agreed they used the feedback effectively.
  • 75% of students who received teacher feedback via GitHub and 65% of students who didn’t receive teacher feedback via GitHub agreed or strongly agreed the feedback was helpful.

Students felt their teachers were more aware of their needs as a student:

  • 68% of students who received teacher feedback via GitHub and 60% of students who didn’t receive teacher feedback via GitHub agreed or strongly agreed the teacher understood their needs as a student.

Support in learning to use Git and GitHub

Students needed more support from teachers and peers when learning to use GitHub. About a quarter of students felt they received less support than they needed from teachers, and about a third of students felt they received less support than they needed from peers.

Implications for Computer Science education

@mozzadrella, who is also an instructional designer, sees important conclusions in the data around developing a sense of belonging and self-efficacy:

This study offers on-ramps to help more people succeed in Computer Science education. We now know that using GitHub in the classroom predicts a greater sense of belonging, which is related to persistence, overcoming obstacles, and overall academic success.

Feedback is a huge piece of learning, and students say feedback delivered through GitHub is both more effective and more helpful. Better feedback leads to better code. This is an urgent insight that will move the entire education field forward.

The last key insight is about student success: Students who use GitHub in their technical courses report being more prepared for future coursework and for work in industry. This has wide-ranging implications for student engagement in technical education.”

As the school year starts, teachers can use these insights to calibrate for the needs of students. Teachers who are looking for help getting up to speed on GitHub can use the online teacher training in Campus Advisors, or sign up to find out more about GitHub Education.

Thank you, GitHub Education

It was an exciting opportunity to conduct this study. As my background is in psychological research, I’m naturally curious about how different variables shape learning. The big questions we took on challenged me to put myself in the students’ shoes. And as a teacher myself, insight to the challenges students face and how resources may be leveraged to boost positive learning outcomes is incredibly valuable. Thank you to everyone who participated in our research. We look forward to sharing more research findings with you in the future.

Read the full report

Changelog

Subscribe

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