rfe: simple framework for post-build checks

Dan Williams dcbw at redhat.com
Thu Mar 23 18:52:04 UTC 2006


On Tue, 2006-03-14 at 22:24 -0500, Bill Nottingham wrote:
> The build system should have a framework where simple post-build
> checks can run. Simple design would be:
> 
> - tests are collected in a package of scripts (or in CVS)
> - packagers can add extra ones for their packages
> - tests have access to:
>   - the build logs
>   - the name of the user who submitted the build
>   - the owner of the package (if not the same)
>   - the previous version of the package
>   - the repodata for the repo being built for
> - tests have a defined return status, such as
>   0 - everythings OK. Carry on, sir!
>   1 - some information here
>   7 - someone should review this and approve before pushing
>       the package
>   11 - the package is bad, please throw away
> 
> These tests could then be:
> - e-mailed to the builder
> - e-mailed to the owner
> - posted on the web
> 
> Doing this allows for simple, automated, QA; it can check that
> things that are caught in the package review for initial import
> are then caught later if they regress, and it can catch other
> things.
> 
> Examples of tests:
> - test for files owned by the compile user
> - test for files with executable stack
> - look for specific compiler warnings in the build output, such as:
>     ... will always overflow destination buffer ...
>     ... warning: format argument XX unused before used argument XX ...
>     *** buffer overflow detected ***
>     ... warning: ignoring return value of 'realloc' ...
> - check for introduced multilib conflicts
> - check the scriplets for:
>   - correct use of chkconfig
>   - correct use of useradd or equivalents
>   - excess complication (warning: package %post is 150 lines)
> - using the repo data:
>   - check the package for broken deps
>   - check the repository for induced breakage
> - using previous version of the same package:
>   - check for added/removed files
>   - check for added/removed/changed dependencies
>   - check for introduction of new setuid files
>   - check that symbols changed in libraries without changing soname
> - heck, just run the package through rpmlint and mail it out
>   (or check it against a known list of exceptions for the package)
> 
> I'm sure people could come up with a lot more. By making it
> a simple framework, it allows for easier contribution.

Sounds like a plan.  We should do this.

Dan





More information about the Fedora-buildsys-list mailing list