[Bug 38879] Add git history/log parser for tinderbox

https://bugs.freedesktop.org/show_bug.cgi?id=38879

--- Comment #9 from Christian Lohmaier <lohmaier@gmx.de> ---
Oh, you misunderstood.

tinderbox shouldn't use the commit's time as reference, but assume that the
tinderbox did start the build right after pulling. 


So tinderbox knows the commits between the intervals where tinderbox does check
for a build, and can use the starttime of the buildbot to map that into this
interval.

Of course this will not be accurate, as tinderboxes can lie about the
starttime, and aren't required to immediately start building after updating the
repo. And of course there will always be multiple commits in the
tinderbox-check-for-update range, hence it is always an approximate list of
changes.

My proposal is a simple one, that doesn't rely on tinderbox slaves reporting
the hash they built, and doesn't look at commit-timestamps at all. As written:
it is a fallback-method.

So assume the timeline:
18:00 (tinderbox server pulls and change-ID foo is at top) and 
18:08 build with status success was started, but didn't provide change-ID
18:15 (chage-ID bar),
[....]
23:00 (change-ID oof)
23:09 build started and result was failure, reported without change-ID
23:15 (change-ID rab)


With the fallback-method, tinderbox will report all changes between "foo" and
"rab" as possible candidates that could have broken the build. No attempt is
made to detect the exact revision that the bot did build.

It is an educated guess, not exact.

The reason why I suggest this method is, that clicking on the timeline in the
overview pages, also used to list all commit since that date, this was trivial
to do with bonsai in the early days, and also no problem with svn later on.
Impossible with the multi-repo stuff, and in reach again with the
onegit/submodules based repo.

As you write yourself: Impossible to tell when then commit reached the main
repo by looking at the commit's date, as that is the local commit time, not the
time it landed in the upstream repo. But when tinderbox checks the upstream
repo regularily, no problem to list that info.

When you rely on tinderboxes reporting the built revision, you still would have
to embed this into a timeline based on the starttime to be able to make the
timeline work. 

But all the above is just suggestions..

-- 
You are receiving this mail because:
You are on the CC list for the bug.