One of the most extended definitions about Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. This approach reduces long periods between build and test runs while simplifying automatic tasks.
Recently, I wrote some lines in Go language to watch like a concurrent Personal Continuous Integration (PCI) code, exporting a REST API over HTTP, could look. Landscape in computing has evolved from desktop computer and client-server architectures to more diverses computing devices and architectures (clusters, cloud, embedded devices ...) Nowadays, running some kind of build bot in your multi-core smartphone or personal device makes sense in some scenarios.
Having a look in classic CI architectures, there are two predominant approaches: master/slave architectures and reporting architectures. A combined approach is possible too.
Buildbot, for example, is a master/slave architecture in which a central server drives remote builds. CDash, on the other side, is a reporting architecture where central server aggregates build reports sent by clients. If you wonder where Jenkins fits, it is a combined architecture. Jenkins provides both modes of operation.
With those two architectures in mind (combined approach included) I found overkill using those architectures to support some personal projects. I think it would be interesting a more simple and light architecture where a set of minimal components provide the core functionality. This way, the architecture would be aligned with frequent stop-and-start actions and fast booting happening in PCI. Keeping all extra functionality out sounds reasonable to get PCI running in devices with power limitations too.
The current implementation uses four main abstractions: builder, build, stage and command. This simple division offers a good balance to schedule real build commands while using concurrency and/or parallelism.
The previous diagram shows dependencies among the different blocks, grey boxes highlight places handling concurrent code and starting goroutines. goroutines are used to run concurrent tasks related to control, web interface or building logic. On the other side, main.go is the place where the design guidelines are implemented.
The code uploaded to GitHub is a simple proof of concept to see the architecture working in Go. The code aligns with the build' sequential logic. The current implementation keeps its configuration in JSON format and it exports a simple HTTP REST API to retrieve information and control the build. One alternative configuration (running configuration) is updated on real-time. It provides a way to recover of crashes and/or stop-and-start actions.
In summary, feel free to play witht the code. It implements some requirements more aligned for personal building and quick deployment. A local concurrent architecture exposing a HTTP REST API is used too.