FTY remerge as of 20250415 with NUT tag v2.8.3-rc4 and 20250421 with tag v2.8.3-rc5

[jimklimov]

Follow-up to #2875 to verify new RC still behaves nice

[teoberi]

Why does NUT CI farm - Jenkins checks take so long a day and almost 9 hours so far in this case?

[jimklimov]

It runs a matrix of several thousand builds with different dependencies and build settings, varied toolkits, compiler versions, distro releases, etc. Quite often just one combo acts up, so quality-wise across the big board this is worth it.

The builds also compete for computers involved, so most of the time scenarios wait in a queue. Currently there are also pre-release "fightwarn" builds with more warnings enabled to check for surprises and running on more obscure platforms (some in QEMU, which also impacts the speed those matrix cells get completed).

The DMF code base also involves more work with generated mapping tables and checking them, so it is a bit of an outlier until it would get merged; a single (non-competing) set of scenarios for a master branch completes in 5-7 hours with no delays due to other jobs.

[teoberi]

It took 2 days and a few dozen minutes to check each of the 3 Pull requests left open in the case of NUT 2.8.3.
It seems a bit long to me, but I hope the wait is over.

[jimklimov]

Well... the architecture is open to people providing their hardware as workers for the NUT CI farm, although the original intent was to register unique workers (like when someone cares for NUT on AIX or HPUX, and has a machine, it could be made available as a swarm agent and dynamatrix cells to test for its toolkits would get generated). So far it is mostly VMs of various linux/bsd/illumos/... systems, some hosted on DigitalOcean donated resources. My home is also heated by one of such machines.

[jimklimov]

That said, a long-standing technical debt around this does exist - to revise the scenario definitions (see Jenkinsfile-dynamatrix and the dynamically generated build matrix summary stored as an artifact with each build), I suspect a certain amount of build scenarios could end up doing duplicated effort needlessly: e.g. it suffices to generate docs once per platform and I am not sure extra generations do not happen (with distcheck or explicitly); maybe some combos of toolkit/language spec/OS/CPU/... pop up independently due to different queries...

It could be beneficial to pore over the list of combos (or teach an AI to do so), and possibly separate them into even more fine-grained definitions (there are already about 20 groups of rules) if any systemic overlaps are identified. Or to find some patterns about this and code better de-duplication in https://github.com/networkupstools/jenkins-dynamatrix where the run-time matrix gets generated based on each build's circumstances (such as the currently seen population of build agents' announced capabilities).

The first step is to indeed pore over those logs to see if the suspicion about undesired duplicates is valid or not. Maybe there is no problem to solve here after all, and all scenarios are unique. This is something I can't bring myself to do, it seems - more urgent priorities take over and this remains a way to train patience..

[teoberi]

It works! It works!
The only thing that still bothers me is the -rc5 suffix!
PS
I disabled support for SSL and USB drivers (which I don't need) and it actually works, including the messages displayed in the console, now nothing scares me anymore!

[jimklimov]

Note that many of the messages (like NUT version banners, SSL not-init, etc.) can now also be silenced with environment variables, commonly exported by an init-script, systemd unit, your shell profile (for CLI commands), etc. - see nut.conf.sample comments for an overview.

[teoberi]

I know, you told me that and I already did it.