Availability of automated buildhistory for master/master-next and YP autobuilder

We've had buildhistory for a while and its long been intended to make better use of it. I'm pleased to say that we now have this available on our automated infrastructure (thanks Beth, Michael and others who've helped!).

The output gets shared into a git repository at:

http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/

For master builds, there are branches like:

http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/log/?h=poky/master/nightly-arm

with one per autobuilder build target. These logs are incremental and data is appended to the previous build data.

master-next poses some challenges since it can be rebased. Right now the autobuilder is pushing a fresh branch each time, e.g.:

http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/log/?h=poky/master-next/nightly-arm

These are reset for each new build. Comparisons can be made against the latest master branch but for now that is a manual process since the autobuilder doesn't know how to map "master-next against master". There are also other branches created for other poky-contrib based builds.

We do need to start analysing this data as it does highlight there are problems within the builds. For example, looking through the latest master packages diff for arm:

http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/commit/?h=poky/master/nightly-arm&id=76be4fa8cbcab7c334ae299188f3c3d7684d5349

why did the attr-dbg package change its FILELIST? It could have been the gcc patch but was it a good change?

The files contained in images is also a bit worrying:

http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/diff/images/qemuarm/glibc/core-image-sato-sdk/files-in-image.txt?h=poky/master/nightly-arm&id=77580baf448a95c6d66f963d112300a0214c233a

The /usr/src/kernel dir/subdir permissions changed. Was that intentional?

/var/lib/sudo/lectured changed into /var/db/sudo/lectured. Why?

I'd love some help going over this output, logging bugs for issues found and then help in fixing the builds. I'm pretty sure there are some serious reproducibility issues buried in there. By that, I mean that two builds which are supposedly of the same revision, have produced slightly differing results.

We do have some tools like buildhistory-diff which are designed to filter the repository data and come up with a list of "serious" problems and filter out normal version changes. We're aware there are shortcomings in those tools but this may give us the push to go and fix or improve them!

Cheers,

Richard

Some additional notes on this. Right now we treat repositories differently depending on how they are whitelisted in the autobuilder.

BUILD_HISTORY_WHITELIST = "{'git://git.yoctoproject.org/poky':['master']}" BUILD_HISTORY_THROWAWAY_WHITELIST = "{'git://git.yoctoproject.org/poky':['master-next']}"

We are capable of extending either of those (and I intend on doing so for at least BUILD_HISTORY_WHITELIST to map to release branches).

I've been thinking about how to do this a bit and it's certainly for 2.2. The first thing I'd like to do however is to take some of the things I've had to do to CreateAutoConf for basic setup (buildhistory makes some assumptions about repos/branches existing) and pull them into buildhistory. All this slows down CreateAutoConf a bit (as we need to do some git ls-remotes).

Once I get some of that pulled into buildhistory we can look at how to do some mapping. Something like:

BUILD_HISTORY_REPO_MAP = "{'git://git.yoctoproject.org/poky':{

'master':[{'git://git.yoctoproject.org/poky':'master-next',

'git://git.yoctoproject.org/poky-contrib':'ross/mut'}]}}}"

Elizabeth Flanagan
Yocto Project
Build and Release