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
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
[[!meta title="Netsurf and Ick"]]
[[!tag netsurf]]
[[!meta date="2019-02-17 16:08"]]
Netsurf (http://www.netsurf-browser.org/) is a lightweight and
portable web browser. It targets several older operating systems, for
which it is often the only graphical web browser.
Netsurf is cross-built for many older operating systems which can not
support native build. It is natively built on a number of esoteric
systems for which cross-building is not possible. For some more modern
operating systems, NetSurf is built for several different toolkits and
target kinds, including some pure-test-related builds whose outputs
are coverage reports, test summaries, etc, rather than executable
artifacts.
NS currently uses Jenkins, but finds it problematic. A particular
problem is that current versions of Jenkins want a version of Java
that is newer than what is supported on some of the systems NS
targets. Jenkins has also proven to be inflexible to use. NS is
interested in replacing Jenkins with Ick, eventually.
The NetSurf project has sunk a significant amount of effort into
making the older Jenkins fit-for-use, so while replacement is
desirable, there will need to be an easy pathway to transition to Ick,
or to have Ick run alongside Jenkins while jobs are migrated piecemeal
over time.
Another significant issue with Jenkins for the NetSurf project is that
of configuration management. Jenkins' ability to be configured without
use of its web-UI is, while not limited as such, unpleasant to work
with. Significant security issues surround the JNLAPI and as such,
given the age of the Jenkins in use, NetSurf are unable to automate
configuration management. A feature of Ick which attracts the project
is the possibility of git-based configuration of the CI system.
However, the project does find the web-UI useful from time to time in
order to make small tweaks to configuration (for example when
debugging a CI job). Ick will need to support some configuration
changes through a web-UI (ideally making and pushing git commits
behind the scenes).
NS is divided into many components, sub-projects, each of which builds
something like a library used by other components. The various
components thus have build dependencies on each other, and if a
dependency changes, any components that build-depend on it need to be
built and tested as well.
Some components are host-based tools which are consumed by many
downstream variants of component builds. For example, the binding
generator is built for each host (e.g. `x86_64` Linux vs. `i686`
Haiku) and is then consumed by any downstream build running on that
host, regardless of its target (e.g. on `x86_64` Linux, a build of
NetSurf targetting AmigaOS).
The NS project hosts its own builders, and there is at minimum ssh
access to them. They may need to have each builder run multiple
workers, to use hardware efficiently. The builders are not all
co-located in the same physical location: being frugal with bandwidth
use is a concern.
All of the builders are linked to a virtual LAN (single broadcast
domain across multiple sites). This means that in situations where
bandwidth is a concern, non-encrypted protocols are considered just as
secure as encrypted ones. While SSH is available to all hosts, some
are perhaps less reliable than others. It would behoove Ick to not
rely on communication purely via SSH if at all possible. Sadly Python
is not necessarily available on all hosts either. A small C-based
agent may be required for maximum flexibility and minimum risk of
TTY/SSH related issues.
NetSurf has CI notifications routed to a number of targets including
the project IRC channel, a mailing list, and an RSS feed from the
Jenkins. In order for these routes to be useful, NetSurf would find
the ability to construct rules in order to filter and route
notifications very useful indeed. For example, every successful or
failed build should not be notified to IRC, instead only when a job
changes state from success to failure or back. Ensuring that
notifications carry useful semantic information and links will also be
desirable.
NetSurf makes use of Jenkins' history of builds, allowing the project
to trace non-fatal issues through builds. These link back to the git
repositories at the specific commits built, and this is considered a
critical feature of the UI.
NetSurf would very much like it if the CI could be easily configured
to deploy branch-based builds in a way which will not confuse artifact
handling, and will allow developers to build a branch across many
repositories in order to simplify the testing of the development of a
new feature which crosses libraries. Such a concept is often referred
to as "system branches".
It would be best if these builds were not created by default for any
branch, but rather that there was a simple way for a developer to
activate a set of jobs for a branch. Perhaps by adding the branch name
to a configuration in Ick via either the web-UI or via the git
configuration. Or perhaps by pattern of branch name.
|
