On Tue, Nov 29, 2016 at 5:17 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Many of us don't have 'all' platforms available at their home or work
place and we sorely miss the Pd-extended build farm with its nightly test builds. It seems useful to share knowledge and experience about an existing infrastructure like Travis.
One option is "Giblab CI" which comes with Gitlab. Essentially you define the build process with a yml file then set up "runners" on whatever machine(s) you want. The runners can be on bare metal or a number of container environments-- docker, virtualbox, etc.
Here's a (still rather crude) example: https://git.purrdata.net/jwilkes/purr-data/commit/326f08b8d6765482068c87e251...
The nice thing about it is that each build machine just needs a single
gitlab-runnerinstance running on it. That process just polls the repo waiting for relevant commits, fetches (or clones) the repo, builds, and optionally uploads artifacts.In my case I'm using the virtualbox backend, so on each commit it clones a virtualbox snapshot, fetches the repo, builds, tests, and then uploads the resulting *.deb package.
The OSX box always fails because I'm trying to build inside a virtualbox OSX guest running under OSX, and for some reason I cannot get OSX to ssh into an OSX guest. Also for Windows you'd have to, well, have Windows. :)
But even without Windows and OSX, having the CI speeds up the dev process by an order of magnitude.
It seems that with Gitlab CI you can configure 'runners' on your own hardware for the project(s) that use it, right? So you can install dependencies and don't need to start with a clean slate for every build? That has several pro's and cons as compared with Travis. More DIY, but still with a standardized API.
Katja
Best, Jonathan