1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
[[!meta title="Ick—roadmp"]]
This is the roadmap for Ick development. It does not stretch very far,
because predicting the future is difficult. This roadmap also doesn't
give any dates, this is a hobby project.
Current development goal
=============================================================================
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 Ick2 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 artifacts are published in a suitable location.
> Builds may also be builds of static web sites or documentation, and
> those build artifacts 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, ick2
> will do that).
[architecture document]: http://code.liw.fi/ick/ick2-arch.html
Acceptance criteria for ALPHA-1:
* All Ick2 components and the workers are deployable using Ansible or
similar configuration management tooling.
* 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 ick2 itself, the
other should build a .deb packages of ick2. Bonus points for
building other projects than ick2 as well.
* Builds get triggered automatically by a git server on any commit to
the master branch.
* Build logs can be viewed while builds are running or afterwards via
an HTTP API (perhaps wrapped in a command line tool). Bonus points
if someone builds a web app on top of the API.
* A modicum of thought has been spent on security and the major
contributors agree the security design is not idiotic. The goal is
to be confident that a future version of Ick2 can be made reasonably
secure, even if that doesn't happen for ALPHA-1.
* The workspace is constructed from several git repositories, e.g., so
that the debian subdir comes from a different repo than the main
source tree.
* The pipeline steps are not merely snippets of shell scripts to run.
Instead, steps may name operations that get executed by the workers
without specifying the implementation in the Ick2 project
configuration.
|
