Hello,
On 29.11.2016 22:33, katja wrote:
On Tue, Nov 29, 2016 at 12:07 PM, katja katjavetter@gmail.com wrote:
[...]
From https://docs.travis-ci.com/user/customizing-the-build/, I understand that Travis CI is also a community build farm (but obviously bigger and more professional than we could organize in Pd community):
'Please take into account that Travis CI is an open source service and we rely on worker boxes provided by the community. So please only specify as big a matrix as you actually need.'
[...]
Oops, 'community' has a different meaning here than I imagined... Travis virtual machines run on Google Compute Engine:
https://blog.travis-ci.com/2015-11-27-moving-to-a-more-elastic-future
Probably paid by private / commercial Travis users ($129 / month). Same business model as Github after all.
Yes, and it makes sense: Leasing a computer from a server farm is really cheap now ("There is no cloud, just other people's computers"[https://fsfe.org/contribute/spreadtheword.en.html#nocloud]), and many FLOSS programmers are working as paid programmers as well, and can then spread the knowledge of these services. The "worker boxes" are the VM images.
Anyway: I have got Travis CI working for building PuREST JSON for Linux amd64 and i386, OS X, and Windows builds.
Windows builds use MXE on Linux amd64 bit with cross compiling, Linux i386 uses a chroot in Linux amd64 (Yes, I know, but http://stackoverflow.com/questions/40824438/compiling-32-bit-binaries-on-tra...), and OS X uses homebrew for installing dependencies.
The packages are then uploaded to my owncloud instance and are available from https://ssl-account.com/cloud.residuum.org/index.php/s/380C60JAabnO7jk
The basic outline: Travis CI is configured with these setups in https://github.com/residuum/PuRestJson/blob/master/.travis.yml
I have split the scripts into four parts: Part 1 (*_before_install.sh) installs the dependencies, and serves as kind-of documentation for setting up the development system (Will add it to the wiki).
Part 2 (*_script.sh) is the real build script, mostly just make, sometimes with parameters specifying that it is a build for a different machine.
Part 3 (*_pack.sh) generates the zip or tar.gz package for upload later. I will add compilation of the manual from the Github wiki to this step as well, as this is what I now do before each release.
Part 4 (upload.sh) uploads the resulting files from part 3 to my Owncloud instance with cURL.
I think, most of the things can be adapted for other packages as well, if necessary, especially for externals using pd-lib-builder like PuREST JSON.
Hth, Thomas