Netsurf ( 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.