Continuous integration in a social-coding world: Empirical evidence from GitHub. **Updated version with corrections**

TL;DR

This paper investigates how GitHub developers utilize continuous integration, examining the influence of contribution types and project features on build success rates in a social coding environment.

Contribution

It provides empirical evidence on the usage patterns of continuous integration in GitHub, highlighting differences between direct and indirect contributions and their impact on build success.

Findings

Direct contributions have higher build success rates.

Project language influences CI success.

Older projects show different CI patterns.

Abstract

Continuous integration is a software engineering practice of frequently merging all developer working copies with a shared main branch, e.g., several times a day. With the advent of GitHub, a platform well known for its "social coding" features that aid collaboration and sharing, and currently the largest code host in the open source world, collaborative software development has never been more prominent. In GitHub development one can distinguish between two types of developer contributions to a project: direct ones, coming from a typically small group of developers with write access to the main project repository, and indirect ones, coming from developers who fork the main repository, update their copies locally, and submit pull requests for review and merger. In this paper we explore how GitHub developers use continuous integration as well as whether the contribution type (direct versus indirect) and different project characteristics (e.g., main programming language, or project age) are associated with the success of the automatic builds.