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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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