From 8483a716b629de1e1b5573f42f438a80f8e06058 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Fri, 26 Jan 2018 18:00:53 +0200 Subject: Change: roadmap for post-ALPHA-1 --- roadmap.mdwn | 100 +++++++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 76 insertions(+), 24 deletions(-) (limited to 'roadmap.mdwn') diff --git a/roadmap.mdwn b/roadmap.mdwn index 0949e70..a2a0866 100644 --- a/roadmap.mdwn +++ b/roadmap.mdwn @@ -1,32 +1,84 @@ [[!meta title="Road map"]] +THIS IS A DRAFT AND UNDER CONSTRUCTION AND DISCUSSION IS INVITED. + This is the road map for Ick development. It does not stretch very far, because predicting the future is difficult. This road map also doesn't give any dates, this is a hobby project. -Current development goal +ALPHA-2 +============================================================================= + +ALPHA-2 is the same as ALPHA-1, except with fixes for bugs and minor +inconveniences, and adding support for multiple workers doing multiple +builds concurrently. + +ALPHA-3 ============================================================================= -The current development goal is to be the first ALPHA version, and is -described in detail in the [[architecture]] document, and is briefly -this: - -> ALPHA-1 of Ick can be deployed and configured easily, and can -> concurrently build multiple projects using multiple workers. Builds -> may be traditional builds from source code, may involve running unit -> tests or other build-time tests, may involve building Debian -> packages, and build artefacts are published in a suitable location. -> Builds may also be builds of static web sites or documentation, and -> those build artefacts may be published on suitable web servers. -> Builds happen on workers in reasonably well isolated, automatically -> maintained environments akin to pbuilder or schroot (meaning the -> sysadmin is not expected to set up the pbuilder base tarball, ick -> will do that). - -Remaining acceptance criteria for ALPHA-1: - -* At least two people (not only Lars) have set up a CI cluster to - build at least two different projects on at least two workers. One - of the projects should build documentation for ick itself, the - other should build a .deb packages of ick. Bonus points for - building other projects than ick as well. +ALPHA-3 is ALPHA-2 but with the following changes: + +> Ick builds and publishes its own .deb packages. It can build both CI +> builds, and release builds. It maintains its own APT repository with +> both CI and release builds. Release builds are built from a PGP +> signed git tag of a specific form. CI builds are built from the tip +> of the master branch, and the upstream and Debian version numbers +> are changed to include the build number so that different CI builds +> can be told apart. + +> The builds happen in containers. The container contains the output +> for `debootstrap` with the `build-essential` package installed. Any +> other build dependencies are installed automatically into the +> container, based on information in the `debian/control` file. + +> A new component is added to do trusted operatations as part of the +> build: ssh access for fetching from git, ssh access for package +> uploads, and PGP signing of package uploads. A project can specify +> which APT repository the .deb uploads should go to. + +The ALPHA-2 high-level architecture will look like this: + + @startuml + actor Developer + component Git + component APT + package "Trusted ick" { + component Controller + component Trusted + component Blobs + } + package "Semi-trusted ick" { + component Worker + } + + Git -> Controller : 1. trigger build + Controller -down-> Trusted : 2. give work + Git -> Trusted : 3. git clone + Trusted -> Blobs : 4. upload workspace + Controller -> Worker : 5. give work + Blobs -> Worker : 6. get workspace + Worker --> Blobs : 7. upload .deb + Blobs --> Trusted : 8a.1 download .deb + Trusted -> APT : 8a.2 upload signed .deb + Blobs -> Developer : 8b.1 download .deb + Developer -> APT : 8b.2 upload signed .deb + @enduml + +Major changes: + +* A **trusted worker** component is added. It never runs untrusted + code, which means code that gets downloaded from the git server. + This means it can hold and use secrets such as SSH and PGP keys. + +* The controller will direct the trusted worker to download source + code from the git server, and upload it to the blob service. + Further, the controller will direct the normal worker to download + the source code blob from the blob service, and to upload the build + artifacts to the blob service. Finally, the controller will direct + the trusted worker to download artifacts from the blob service, PGP + sign the .deb files, and upload them to an APT repository. + +* The **APT repository server** component is added. It will only + accept uploads from the trusted worker. It will have both CI and + release builds, but keeps them separate so that users may choose + which to install. -- cgit v1.2.1