[PD] Continuous Integration for Externals

[katja]

On Tue, Nov 29, 2016 at 5:17 PM, Jonathan Wilkes <jancsika at 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/326f08b8d6765482068c87e2516df45d8f165768/builds
>
> The nice thing about it is that each build machine just needs a single
> `gitlab-runner` instance 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