[haiku-development] Re: Package buildmeister

  • From: "Alexander von Gluck IV" <kallisti5@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 19 Jun 2016 19:15:02 +0000

June 19 2016 2:11 AM, "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx> wrote:

On Sun, Jun 19, 2016 at 04:13:06AM +0000, Alexander von Gluck IV wrote:

I worked on getting the haikuporter build-master installed in a public VM 
tonight and
ran in to quite a few concerns about it. The number one issue I saw was the 
requirement
that each Haiku build-slaves be accessible via IP + SSH

Given these machines generally run behind user NAT's, and is "single-shot" I 
think the
haikuporter build-master might be *too* simplistic.

We've collected up quite a few package builders now. Here is my personal 
analysis.

I'm trying to remain independent and honest in my list given I have a horse 
in the race
(and old, un-maintained one)

I think we're all assuming haikuporter build-master is a lot more magic than 
it actually
is. Some great work has been put into it, but I want to make sure there is 
consensus
that haikuporter build-master is the way to go.

https://github.com/waddlesplash/haiku-kitchen
haiku-kitchen (waddlesplash)
Pro
- Runs as a service

I don't understand why this is a "pro"?

The others run continuously and build packages continuously... like a build 
system. CI ftw.

- IRC client

Our IRC channels are getting quite noisy with many notification bots.
Are we sure we want even more of that?

Fair, but we have the option :-)

https://github.com/haikuports/haikuporter
haikuporter build-master mode (mmlr)
Cons
- SSH's out to slaves and requires user to open ssh port per slave. (and 
static ip)

Reverse-SSH can be used, IIRC.

I can't find any documentation, arguments, or code on this... it seems this 
should be
the default behavior for the outlines reasons. (Since we need one complete 
haikuporter
build-master per architecture, how would this even work?)

If anyone wants to try and document it let me know and i'll give you access to a
buildmaster *and* a remote buildslave.

- *Basic* html report of each single-shot run.

... but conveniently exports a JSON file with all the required data to
build or plug a better one (possibly some code from the other projects
could be reused here?).

This sounds more like a Pro to me, it means we can leave the core server
untouched and toy around with the web interface. Or we could write a
native Haiku app or whatever. Modularity is good.

I'm all about microservices, but my main concern is this whole thing sounds
like it is going to be held together via 30 cron jobs, 10 scripts in 
/usr/local/bin,
and a few old men to log in and manually fix stuff every other day.

- Single shot for one package (or a bunch? --do-bootstrap seems broken here) 
and deps

Which is what we need to trigger it as a git post-commit hook (on all
changed recipes). I still don't get the idea that this should be an
external service

This sounds more like a Pro to me, it means we can leave the core server
untouched and toy around with the web interface. Or we could write a
native Haiku app or whatever. Modularity is good.

The thing is single shot anyway and we'll have to run a complete instance for 
each
architecture... so I fail to see the "leave core alone" argument.

The git trigger is a good point. I didn't think about it from that perspective.

- Poor documentation (I've written whats out there now)

And mmlr sent mails to our mailing lists describing things a bit. That's
not documentation, but it could be turned into some.

Example?  I've spent a bit of time searching ML threads and can't find any
details or example usage.

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 06-2016