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
59
60
61
62
|
[[!meta title="Ick requirements"]]
This page collects requirementts for the Ick CI/CD system. It doesn't
cover requirements for related projects, which have their own pages
([[Muck]], [[Yuck]]).
All of this document is open for discussion, clarification, and more
detail and to be made more specific. For example, many requirements
don't have an actual acceptance test or measureable goal. Help adding
those would be welcome!
Stakeholders
=============================================================================
* USERS: Those who develop their own projects, and need a CI or CD
system for helping them do that. They will use an Ick hosted by a
HOSTER (which might be themselves, wearing another hat).
* HOSTERS: Those who host Ick for themselves or others to use.
* CONTRIBUTORS: Those who contribute to Ick itself. This includes
those who write code for Ick, or documentation, translate the
software or documentation, those who support Ick users, etc.
Requirements
=============================================================================
Each requirement has an ID (shown in upper case) so it can be referred
to easily, if need be.
* FREEDOM: Ick must be free software.
* HOSTABLE: Ick should be "hostable": those interested in doing so,
should be able to provide an Ick instance for other people to use,
without having to truse those other people. Hosters should be able
to charge money for hosting Ick.
* MIGRATION: Users should be able to pick any Ick instance they trust,
and migrate between instances.
* ISOLATION: Ick users should feel safe that their projects, builds,
and build artifacts are unaffected and secure from prying by other
users.
* SECRETSTORE: Ick should provide users with a secure way to store
"secrets", such as SSH keys, PGP keys, and API access tokens, and
use them securely in their projects, without the secrets leaking to
other users.
* SPEED: Ick should run builds reasonbly fast, without causing much
overhead.
* CONCURRENTBUILDS: Ick should be able to build different projects
concurrently, whether for the same user or several.
* CONCURRENTACTIONS: Ick should be able to build parts of a project
concurrently, when the parts don't depend on each other.
* CONTAINERS: To simplify running them in containers, as few Ick
components as possible should store data persistently, and should
instead store them in backing services that are meant for persistent
storage.
|
