[Slackbuilds-users] SlackBuilds.org automated build system [was: Help offer]

[Andrzej Telszewski]

On 06/11/16 17:56, Andrzej Telszewski wrote:
> On 06/11/16 12:47, David Spencer wrote:
>> I haven't discussed this with anybody until now, but maybe buildbot
>> could be useful to us. Unless I've made a mistake reading the buildbot
>> docs, it would allow people to volunteer their own systems as build
>> hosts. There are a couple of things we would need to worry about -
>> clean build environment, authentication - but the idea would seem to
>> fit a project like SlackBuilds.org that tries to exist with minimum
>> infrastructure of our own.
>>
>
> Although people volunteering their systems sound appealing, I wouldn't
> go that direction.
> You know how it goes, everything is fine until it's not.
> It is much better to have system that you have total control over.
> Then it's only you that is responsible for the system's security and
> also you don't have to worry about volunteer's system security.
>
> Capable machines are dirt cheap.
> For 20 euro/month you can have 8C/8T @ 2.4 GHz at https://www.online.net/
> I can easily donate such machine.
> Or gather 10 people, we pay 4 euro/month and you have two capable machines.
>
>> I've got a draft SlackBuild for buildbot-0.9.1, but since 0.9 it's one
>> of those packages that need to download huge quantities of npm stuff
>> at build time :(
>>
>
> Brr. I know it is 2016 and I should love Java and JavaScript, but I don't.
> If you go this direction, I will try to do my best to help, but don't
> count on it too much.
> Orthodox would apply to me very well in that respect ;-)
>
> What I've been thinking of is brewing our own (because it's much cooler
> :-)) build system.
>
> Quick draft would be:
> - QEMU, for isolation from the host system,
> - overlayfs -> chroot -> build tool, for keeping the system clean (you
> understand it correctly, i.e. slackrepo would run in overlayed chroot,
> creating its overlays/chroots inside),
> - running everything from single QEMU instance would probably allow for
> easier memory management,
> - some way of sending the SlackBuild, either tarball or something that
> is run based on git push (I have just started studying git, so I don't
> know yet its capabilities),
> - some way of receiving/monitoring the build status.
>

Alternative, or probably better approach than QEMU would be to use some 
of the available sandboxing technologies.

We install full Slackware into one directory.
Then this directory is overlayfs mounted on another directory.
Then this another directory is passed as rootfs to the container.
Then the build tool runs in the container.

I have no experience with containers, so I cannot tell how viable would 
it be.

-- 
Best regards,
Andrzej Telszewski