Re: Build failure tooling improvements

[Jonathan Perkin <jperkin%pkgsrc.org@localhost>]

* On 2025-03-20 at 19:35 GMT, Benny Siegert wrote:

> Am 20.03.25 um 18:29 schrieb Jonathan Perkin:
> > So, how about a different approach.  What would you like me to work 
> > on? What features would you like to see, and would actively use?  
> > What is your ideal workflow?  What would it take for your workflow 
> > to include cross-platform checks prior to commit?  What resources do 
> > you need to help ensure each individual commit is as high-quality as 
> > possible?
> Maybe a post-commit hook to build the package and its direct 
> dependencies after a commit?
> In the src tree, there is a list where post-commit build failures are 
> posted by a script, and that way they are usually fixed quickly.
My preference would always be for something pre-commit so that the tree 
is always high quality, but I understand that the vast majority of 
committers want a commit-first-fix-problems-later model, so, ok.
The way I'd do this is collate all of the touched packages in a certain 
time-frame, and insert them into limited_list bulk builds running on 
multiple platforms.  The reports would then be sent to pkgsrc-bulk 
(perhaps excluding 100% successful builds to avoid too much spam), and 
any failures would be emailed to the committers responsible.
Other suggested features would include running pkglint on the files and 
again emailing any failures or suggestions, and configuring multiple 
bulk builds for the same platform (probably NetBSD for the widest 
coverage) but with different PKG_OPTIONS to test for e.g. 'doc' fallout, 
non-default PREFER_*, PKG_SYSCONFDIR, etc.
The simplest way to do this would be to create some workflow triggers in 
a .github directory at the root.  I know some people have a strong 
aversion to GitHub, but this would be practical for a number of reasons, 
with one of the more compelling ones that the conversion sync always 
waits for a quiet period, so this would avoid builds being triggered in 
the middle of a large update and resulting in unnecessary failures.
If people are willing to get behind this then I'm more than happy to 
work on it, and I can provide hardware to run builds for multiple 
operating systems.
--
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com