Return-Path: 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 ; 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 ; 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 ; 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 ; Sun, 17 Feb 2019 16:13:44 +0200 (EET) Date: Sun, 17 Feb 2019 16:13:43 +0200 From: Lars Wirzenius To: Ick discussions 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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==--