<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Add git history/log parser for tinderbox" href="https://bugs.freedesktop.org/show_bug.cgi?id=38879#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Add git history/log parser for tinderbox" href="https://bugs.freedesktop.org/show_bug.cgi?id=38879">bug 38879</a> from <a class="email" href="mailto:lohmaier@gmx.de" title="Christian Lohmaier <lohmaier@gmx.de>"> Christian Lohmaier</a> <pre>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..</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>