gohci got an upgrade
Chat on Slack
@periphio
Edit this page
Since my day job is working on continuous integration systems (CI), when I started periph.io I really wanted to have a strong testing system to make sure regressions wouldn’t go undetected.
The challenge is that first, I’m cheap, and second, I needed it to run tests on my Raspberry Pis, macOS and Windows machines without any maintenance, both before and after accepting PRs.
On one Sunday afternoon in November 2016, I hacked up what eventually became gohci.
The requirements are simple: it needs to be specialized for Go projects, like native support for canonical import path, run on all the platforms supported by periph.io, be lightweight so it would run well on a single core system with 512Mb of RAM like a BeagleBone or a C.H.I.P., be free, and without servers to maintain.
What hit me on that Sunday is that GitHub gists are free, can contain multiple ‘files’ and a GitHub machine account can do 5000 requests per hour, including sending commit status updates. That’s all that was needed to start the initial prototype.
The end result is something that can conceptually thought of similar to Travis, except that instead of specifying a single set of commands to run that is run on a linux VM that is provided by them, you specify one set of commands to run per worker, and you provide your own workers.
This enables running completely different smoke tests on different hardware. For
example I have tester boards
(created by the amazing tve) on many of the micro
computer, which is tested via periph-smoketest *-testboard smoketests. We run
GPIO performance benchmarks. The Windows gohci worker has a
FT232H which is tested specifically,
and the MacBookPro has a FT232R.
This results in files like periph/.gohci.yml and extra/.gohci.yml which contain specialized checks, based on the specific needs of the project.
Worker configuration is really simple, upon its initial execution,
gohci-worker writes a gohci.yml file that contains everything needed except
the machine account OAuth2 access token. You fill it in, front the worker via an
HTTPS proxy like caddy and you’re good to go.
To start getting checks to run, add a webhook to each GitHub repositories you want to tests, one webhook per worker. You create M x N webhooks, for M repositories for N workers. And you’re up and running!
The test result looks like this, in this case it ran on Windows 10 and tested that a FT232H is working correctly.
Questions? See the FAQ.
Want to learn more? See the configuration documentation.
Comments? Join the periph.io slack channel. Need an account? Get an invite.