[Buildbot-devel] force requests under original buildset

[Jorge Gonzalez]

Thanks for the detailed reply.

On Thu, Oct 4, 2012 at 9:29 PM, Dustin J. Mitchell <dustin at v.igoro.us>wrote:

> So, I think you're suggesting adding build requests to a buildset
> after the buildset is created.

Yes, that's what I was suggeting.

>  Of course, you're free to do what you
> want locally, but in general I don't think that's a good idea:
>  * buildsets' status is based on a summary made when the last
> buildrequest is complete.  If buildsets can be added later, then there
> are all sorts of interesting questions about when a buildset is "done"
> and what its status is
>
Good enough reason not to alter them.

>  * Modifying a buildset after the fact gets away from the largely
> write-only

did you mean read-only?

> nature of objects in Buildbot, which is a building block of
> the data model in the data API
>
> The problem you've identified is a real one, though, and I've been
> thinking a bit about it lately.
>
> First, what are buildsets good for?  Buildsets are the unit by which
> builds are *started*, and to that extent basically only exist for the
> dependent scheduler.


> However, now that we have multiple codebases, buildsets also represent
> the point where those codebases are tied together to select a
> particular set of sourcestamps.



 I think the kind of questions you're looking to answer with buildsets
> are better answered directly from sourcesetamps.  However,
> sourcestamps aren't very well organized right now -- there are *lots*
> of duplicate sourcestamps in the database -- and some of them are
> relative -- making it difficult to tease out all of the builds for a
> particular piece of source code.
>
Indeed. In fact, after sending my email I kept on looking at my DB in more
detail and realized that forced rebuilds actually create yet another
sourcestamp with everything remaining equal to the original with exception
of its ID. This fact is making me consider starting from the Changes, and
work my way up to Builds...  pretty much navigating all the object
hierarchy.

>
> I think the better way forward involves:
>  - making sourcestamps unique, so a sourcestampid uniquely identifies
> a particular version of the code in a codebase
>  - adding the right indexes to allow queries for builds for a
> particular sourcestamp to be performed efficiently
>  - disallowing relative sourcestamps - make them absolute at the time
> they are created (requiring changes to changesources)
>  - encoding extra information about the relationship between
> sourcestamps in the changes table (basically, parent pointers for
> changes)
>
I take you want this because you are not assuming that changes will
necessarily be brought into buildbot in a chronological order that honors
their topological order in their original trees?

>
> I'm working on some of this (the first two points) in nine, while
> laying the groundwork for the rest.  It's all on my laptop right now
> (just got started a few days ago), but I should have some working code
> sometime next week.
>
> Dustin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20121008/9a9046de/attachment.html>