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
- Hosts a web page of build statuses
- IRC client
- Runs continious builds
- Python client runs on slave and pulls work, no inbound connections to slave
- Runs recipe lints on buildslaves
- Documentation
Cons
- Node.js has extremely limited haiku community knowledge
- Reinvents the wheel a lot (down to protocols at times)
- Doesn't rely on haikuporter dependencies enough, tries to solve
dependencies itself.
https://github.com/haikuports/haikuporter
haikuporter build-master mode (mmlr)
Pro
- Python which has good community knowledge
- Fully leverages haikuporter internal logic for dependencies
- Builds repos
Cons
- SSH's out to slaves and requires user to open ssh port per slave. (and
static ip)
- Requires haikuporter + haikuports on master and each slave (does
haikuports have to be in sync?)
- Difficult slave configuration + lots of directory settings per slave
- Doesn't know about architectures of buildslaves (one entire environment
for each arch)
- *Basic* html report of each single-shot run.
- Single shot for one package (or a bunch? --do-bootstrap seems broken here)
and deps
- Lots of requirements on build-master system (package, package_repo, haiku
repo for licenses)
- Poor documentation (I've written whats out there now)
https://github.com/kallisti5/haikeuken
haikeuken (kallisti5)
Pro
- Runs as a service
- Ruby which a few community members know
- Fancy rails web ui w/bootstrap
- Maintains current package and recipe database
- Ruby client runs on slave and pulls work (REST api), no inbound
connections to slave
- Slave config changes without server restart
- Stores and displays recipe info and lint status
- Documentation
Cons
- Dumb dependencies. Sees a package needs built on an arch and builds it on
a matching slave
- Requires a full database back end
- Packages get built, repo upload still incomplete
- Code has gone a bit stale over time (needs updates + finished)
- Was my second big rails app... cleanup + refactoring likely needed
- Rails seems to be on the decline in new code
Looking for comments + feedback.
Us having a basic package build system is one of the last big blockers for a
release.
-- Alex
