From 0f23b251f378ea4c2b8b98e25d9aaea7681787e1 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Sun, 17 Feb 2019 16:09:06 +0200 Subject: Publish log entry --- blog/2019/02/17/netsurf_and_ick.mdwn | 97 ++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 blog/2019/02/17/netsurf_and_ick.mdwn diff --git a/blog/2019/02/17/netsurf_and_ick.mdwn b/blog/2019/02/17/netsurf_and_ick.mdwn new file mode 100644 index 0000000..6c8ebde --- /dev/null +++ b/blog/2019/02/17/netsurf_and_ick.mdwn @@ -0,0 +1,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. -- cgit v1.2.1