Change: roadmap for post-ALPHA-1

1 files changed, 76 insertions, 24 deletions

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.