The programs that deliver our favorite online services continuously evolve. For all programs, a team of programmers constantly modifies some parts of the code to add cool features, to improve the interface or to make the service faster. For example, 8790 changes have been applied on the Chrome browser in the last month. Each change is called a commit. Each commit can modify a few lines up to hundreds of lines of code. The 8790 commits have been contributed by 1004 different programmers.
In order to make sure that all these changes do not contradict each others or do not completely break the service, it is important to regularly put the commits of different developers together and test the service. A Continuous integration (CI) engine is in charge of automatically collecting the commits, putting them together and testing the program. Each time the time the CI engine integrates one commit, it runs a build.
For this hackathon, we focus on one CI engine: Travis CI. We have selected it because it helps the developers of thousands of open source project to make sure that the changes they contribute are correct. Travis CI is literally the factory where the key components of the modern web and mobile applications are built. Here, we give a short introduction to Travis CI that is targeted for the hackathon. Interested readers can learn much more about TravisCI
Open source projects hosted on Github can register to Travis CI by inserting a
travis.yml file in their repository. This file includes instructions for Travis to build the project when a commit is pushed on the repository. Then, every commit triggers a build. For every build, Travis CI clones your GitHub repository into a brand-new virtual environment, and carries out a series of tasks to build and test your code. If one or more of those tasks fail, the build is considered broken. If none of the tasks fail, the build is considered passed and Travis CI can deploy your code to a web server or application host.
The hackathon participants have access, in real time, to every build that is performed in Travis. This represents an extraordinary intense activity that we wish to render through visual and sound pieces of software art. These pieces can render different aspects of the stream of software builds, extracting information for the commit messages, the programming language, the duration of builds or from the project that is built.
The Travis websocket provides a stream of information for each Travis Job. This means that there can be several Travis jobs for one specific commit, i.e., there is one job for each configuration. Moreover, the websocket also contain different events: “job”, “updated_job”, and “finished_job” it means that you can receive several time the same job from the API.
The possible states for one Travis job are:
It is possible to identify unique build using with
build_id and a unique job with