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