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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Return-Path: <ick-discuss-bounces@ick.liw.fi>
X-Original-To: distix@pieni.net
Delivered-To: distix@pieni.net
Received: from yaffle.pepperfish.net (yaffle.pepperfish.net [88.99.213.221])
by pieni.net (Postfix) with ESMTPS id D215D42FF6
for <distix@pieni.net>; Sun, 17 Feb 2019 14:13:46 +0000 (UTC)
Received: from platypus.pepperfish.net (unknown [10.112.101.20])
by yaffle.pepperfish.net (Postfix) with ESMTP id AF11C41CA7;
Sun, 17 Feb 2019 14:13:46 +0000 (GMT)
Received: from ip6-localhost.nat ([::1] helo=platypus.pepperfish.net)
by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian))
id 1gvNCU-00082O-KQ; Sun, 17 Feb 2019 14:13:46 +0000
Received: from koom.pieni.net ([88.99.190.206] helo=pieni.net)
by platypus.pepperfish.net with esmtpsa (Exim 4.80 #2 (Debian))
id 1gvNCT-00082C-Cv
for <ick-discuss@ick.liw.fi>; Sun, 17 Feb 2019 14:13:45 +0000
Received: from exolobe1.liw.fi (unknown [194.157.43.230])
by pieni.net (Postfix) with ESMTPSA id EDAC942FF6
for <ick-discuss@ick.liw.fi>; Sun, 17 Feb 2019 14:13:44 +0000 (UTC)
Received: from exolobe1.liw.fi (localhost [127.0.0.1])
by exolobe1.liw.fi (Postfix) with ESMTPS id 5F5D7120B54
for <ick-discuss@ick.liw.fi>; Sun, 17 Feb 2019 16:13:44 +0200 (EET)
Date: Sun, 17 Feb 2019 16:13:43 +0200
From: Lars Wirzenius <liw@liw.fi>
To: Ick discussions <ick-discuss@ick.liw.fi>
Message-ID: <20190217141343.GA13153@exolobe1.liw.fi>
MIME-Version: 1.0
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Pepperfish-Transaction: 158c-1786-233f-696d
X-Pepperfish-Transaction-By: platypus
Subject: Netsurf and Ick
X-BeenThere: ick-discuss@ick.liw.fi
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: discussions about the ick CI system <ick-discuss-ick.liw.fi>
List-Unsubscribe: <https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi>,
<mailto:ick-discuss-request@ick.liw.fi?subject=unsubscribe>
List-Archive: <http://listmaster.pepperfish.net/pipermail/ick-discuss-ick.liw.fi>
List-Post: <mailto:ick-discuss@ick.liw.fi>
List-Help: <mailto:ick-discuss-request@ick.liw.fi?subject=help>
List-Subscribe: <https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi>,
<mailto:ick-discuss-request@ick.liw.fi?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5734649414014469215=="
Mime-version: 1.0
Sender: ick-discuss-bounces@ick.liw.fi
Errors-To: ick-discuss-bounces@ick.liw.fi
--===============5734649414014469215==
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
(Also posted to the Ick blog:
https://ick.liw.fi/blog/2019/02/17/netsurf_and_ick/)
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.
--=20
I want to build worthwhile things that might last. --joeyh
--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAlxpbBYACgkQbC+mFux6
IDHp7g//V0Ygkzhw4EfQd79s/sUL6A3F2oTm8sRQmx577YOsArLNu5E8W4nENdFO
Qd8IZhqN2tQW2vvubhHcPKfwcHNjeTtu4Di/D20xvxFX7xw1d2cr+6JMTBtlBJEP
A7hlovwH//yC6GGi3F6P7k2lP7oOi0lhjWWL5snyCGtIEvMhj8fKpXQNF2jnxoYd
XD0PtT6Yis+q9EEv9C3oy1ffOgS94QEAQiw4STLtruHDK96hDpRmFfVjQXrnSuAH
lbmfgjhs4e8U3RBmijXZB6sGC4m23kLHh/+01vQjAn6Lv6tC9/GY5l5vGBpgjVsR
s3fmrgv2JhATIXSnZVM/Ed9YGrU4FIp94DlLph/tufm49hA9tCh2tlboL+jDBQYU
B7UkNS6+qzDHte2FNcRuEls9SFqnJLa4Y9/0xsjIc1huXyLgI3CzHJfORf55Z2W4
DSCTaiaTHisibbrHRQdqA++Vr69hyfBcZMpgy2HqSK2kt5veGHCS6FNBLIxMYPNe
ULwpd5fKD3+QStT5KEDFgRQgnOrCrzBBCGiw2pFBt64EUau6Dl5/r8umJJjhhNAX
q3Q50jF0Ys1krG+FV+/7dnhZ36AvbcdzjdFUAkn51tyOGFFYaYvYJ9o/pEyOs0FH
U+qfnlmobk8S3mv0QmixGLucBRqJj/0oiK1+6azkLUhXhUtCavE=
=spdc
-----END PGP SIGNATURE-----
--VS++wcV0S1rZb1Fb--
--===============5734649414014469215==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
ick-discuss mailing list
ick-discuss@ick.liw.fi
https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi
--===============5734649414014469215==--
|
