Finding recent development iteration artifacts

Intro

Various systems associated with the NUT CI farm emit artifacts (usually short-lived, from a few days to 3 months, as the cache on those systems rotates) which people can download as an alternative to building from a Git checkout. Most of the routine remains similar, except you may avoid the ./autogen.sh step, and it is harder to iterate (or fetch minor code updates) as a developer or troubleshooter.

Some reasons for pulling such artifacts are:

• "Dist tarballs": Not all systems can generate man pages, while local packaging recipes (or user needs) can require that. Git sources contain only text files with asciidoc markup, while standard "dist tarballs" include pre-rendered pages which the installation operation can just copy.
• Packages: Users interested in just updating NUT binaries to a specified version for their system can fetch those, whichever consistent repeatable way they were built by CI.

WARNING: Note that currently the NUT project does not formally distribute packages well integrated with any particular OS distribution: the packages or equivalent binary archives are really a by-product of having the program files built for testing, with one test step involving make install. Notably, they may also be larger than a release package made by a distro might have been, due to possible presence of debug symbols, etc., and separation into sub-packages may differ from what an official package recipe for a distro might deliver.

See also:

• https://github.com/networkupstools/nut/releases
• https://networkupstools.org/download.html
• Links to distribution packaging recipes and repository sections

Dist tarballs

A standard concept in open-source building, these distribution archives aim to minimize the tooling needed on the ultimate builder's system to just the compilers and dependency libraries. Some generated and added scripts (including those from GNU autotools), as well as manual pages rendered from text into a "*roff" format, and other resource files, are included into such archive.

These archives are now generated for each coding iteration. Sadly, it is too well hidden (GitHub Actions security won't let us customize the Details URL of a GHA job, unless it is associated with a registered application), so a few pictures may be better than a lot of words.

• For a recent build, there is a status icon seen in the main project page or many other spots where commits are shown. For the "master" branch hopefully it is green, although sometimes some system hiccups -- but that's mostly Appveyor CI timeouts. You can click it:

• The pop-up has same layout as a build status seen in pull request pages. There you can go to "GHA-01 ... tarballs" job:

• ...and switch to its "Summary" tab, and down to the right there is the download link:

And in that ZIP (posted as one artifact of this GHA job) there is the standard dist tarball (with pre-built configure script, NUT SEMVER data files, and man pages, among other things), as well as some additional files (rendered docs; checksums for dist tarball):

RPM and DEB packages

• Similar to the above, a status from various OBS jobs would lead you to the Open Build System location for this branch or PR build:

• On top of the OBS package page, you can see the common download link:

• The next page lists different distributions the latest iteration here succeeded for, so you can install a package repository to pull from or grab individual packages for your platform:

WARNING: As of this writing, the reference packaging recipes (under scripts/obs in NUT sources) are primarily seen as a way to get OBS to test NUT builds on numerous build environments, and the resulting packages are a by-product of that. The SPEC/DSC recipes are based on an older copy of what distros served a decade ago. Modernization is planned sometime in the future, but now these packages may be or not be good substitutes for what your OS provided. The Building NUT for in-place upgrades or non-disruptive tests routine may do a better job at updating your existing installation.

NUT for Windows via Appveyor CI

• Like above, seek the Appveyor CI build status (sometimes it is red, if the job run time exceeded 1 hour; it often survives the tests and succeeds posting the artifacts before that):

• There is an Artifacts tab with a 7-Zip archive of the make install prototype location including third-party FOSS libraries needed by the binaries in this or that directory (they should be hardlinks for copies in neighboring directories, but interpreting that as one or many files to write is subject to Windows when unpacking):

• If you go from https://ci.appveyor.com/project/nut-travis/nut/history page, note that builds are all sequentially numbered regardless of whether they are PRs or feature/master branches. Pay attention to the gray details in fine print to get the build YOU want to deploy (whether looking for latest build of master, or of a pull request trying to fix your issue, or when comparing latest behaviors to an older iteration identified by specific source code commit hash):

The NUT for Windows builds prepared by Appveyor CI are "portable", meaning you can unpack them into any directory (e.g. C:\Program Files\NUT, or D:\NUT, or onto your Desktop) and they are expected to work. You may also remove the "extra" directory layer mingw64 seen in the archives (and kept there to help differentiate from possible 32-bit builds). Default built-in cross-references between programs, configuration files and other resources are based on relative paths for that platform.