This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Project:Build Service
| Gentoo Build Service | |
|---|---|
| Description | Deploy privately a build service for building and testing Gentoo packages. |
| Project email | |
| IRC channel | #gentoo-buildservice |
| Lead(s) |
No lead election date set |
| Member(s) |
|
| Subproject(s) (and inherited member(s)) |
(none) |
| Parent Project | Gentoo |
| Project listing | |
The Gentoo Build Service project will have as aim to provide a software and relative ebuilds that would offer a way to deploy privately a build service:
A web interface that exposes API to control remote workers (a cluster of builder nodes) that can build packages as a set of repo with specifications that indicates the packages, the steps, and the desired customizations (useflags, keywords, local ebuilds override, ecc..). Workers will build packages on top of a container or a VM - with support (at least) for Docker.
In such way, the webui can be hooked also to Github repositories, and build-test against Pull requests or changes of an overlay, and even the Gentoo tree, with the option to publish the generated artefacts thru the web server.
The project is still in early stage, so consider this page under construction yet.
Project status
Code is still experimental and in alpha state, and it's not suitable for deployment, usage is strongly discouraged unless for development purposes. Documentation is also missing.
If you are experimenting it - do it locally or do not expose the service outside your network. It is composed already of a server (master), a CLI and an agent executable for bringing up nodes to the cluster. Configurations can also be managed with etcd.
A (skeleton) web interface is available to display tasks overview and starting new builds, it's also possible to see the build live from the webui. It currently allows remote building: nodes are executing the steps inside a Docker container or a Vagrant environment, the content originated from it is managed and can be published. Nodes are communicating with a broker which can be MongoDB, AMQP (e.g RabbitMQ), Redis, AWS SQS, memcache, Dynamodb.
The repositories containing the tools are currently here and in the Build Service Project organization on GitHub.
User contributors
| User | Name | Role |
|---|---|---|
| geaaru | Daniele Rondina | Developer |
Development plan / TODO
- Implement syncing of artefacts [Done]
- Handle Namespaces (tag, publish) [Done]
- Handle GitHub webhooks [Done]
- Implement Users/Groups and login system [Progress/Done]
- Nail down security aspects
- Documentation
- Release