Building Tools with GitHub

Chapter 5. .NET and the Commit Status API

At the risk of oversimplifying things too much, one way to look at a Git repository is as just a long series of commits. Each commit contains quite a bit of information: the contents of the source files, who created the commit and when, the author’s comments on what changes the commit introduces, and so on. This is all good stuff, and works very well for Git’s main use case: controlling the history of a software project.

GitHub’s Commit Status API adds another layer of metadata to a commit: what various services say about that commit. This capability primarily shows itself in the pull request UI, as shown in Figure 5-1. Each commit in the pull request is annotated with a symbol indicating its status—a red “×” for failure or error, a green “✓” for success, or an amber “•” to indicate that a decision is in the process of being made. This feature also surfaces at the bottom of the pull request; if the last commit in the branch is not marked as successful, you get a warning about merging the request.

Figure 5-1. Commit status in the pull request UI

The most obvious application for this feature is a continuous-integration service. A program like Jenkins will get a notification when new commits are pushed to a branch, run a build/test cycle using the new code, and post the results through the Commit Status API. An application ...