Stefano:
See my responses below.
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote on 12/10/2004 02:21:48 PM:
> [EMAIL PROTECTED] wrote:
> [...]
> > In my Build Results system, I have a schema that also includes a few
> > additional things:
> >
> > - abritrary groupings of projects, which helps in organizaing various
> > forms of the presentation of the data
>
> Can you elaborate more on this?
Yes, it is a many-to-many relation between the Project and Group tables.
Thus, I can define one group which is all "mainline" builds (we have
several release streams managed by separate branches), regardless of
platforms build on. Another group would be all Windows/2003 builds. It
is merely a way of seeing a limited set of project names, though when
presented on the web page, I do also display some project attributes for
each project displayed, like the lable & link of the current build as
well as the "last good" build.
> > - the general notion of "attributes" associated with each:
> > - build (instance)
> > - project
> > - group
> > - the whole system
>
> "attributes" as in "annotations" or as in "related data"?
I'm not sure what is the difference between annotations (like added
noted, do you mean?) and "related data". But what these tables do
is, basically to allow one to add new fields to the associated table
without a schema change. They are name/value pairs, with the added
key (foreign key) of the id of the table to which they relate. Thus,
for the Project table:
Project Attributes:
- proj_id (foreign key)
- name (string, key)
- value (blob)
Project:
- proj_id (key)
- ... etc ...
In the case of the system wide attributes table, there is no "id"
field. That table I use for stuff like debug on/off/level, motd,
and so far little else.
> > And since my system is focused on creating interaction between people
> > about given built baselines, I have the notion of a notes history
> > associated
> > with any given build, in a similar spirit as the comment history of a
> > given
> > "bug" in bugzilla.
>
> I like the concept of allowing bugzilla-style communication to happen
> without requiring people to subscribe to various mail lists, like a
> common ground for communication to happen.
>
> But I don't want this to be too global, because I want gump-related
> discussions to happen on the mail list.
You could tie-in email notification when this table is updated. We
don't do that, but it's not a bad idea. Bugzilla of course does this.
> > Like the notes table, I have separate tables for (references to)
> > artifacts,
>
> yes, the artifact table is missing, that's a good point.
I use the notion of an external Artifact Repository and refer into
that with this table. The artifacts themselves are not stored in
the database nor on the database server. Just wanted to be clear
about that.
The notion of an Artifact Repository: ah, well, I have my idea of
what I want, and then there's the reality that we don't have much
more (at present) than a web-based storage mechanism, organized
hierarchically within the file system. Thus "version information"
is exposed in the file-path name space, and 3rd party artifacts
are managed in yet another system. My notion of an Artifact
Repository would be a place to store any 3rd party artifact that
any build could depend on. Build themselves would be producers,
but could also be consumers. One of the main points of this is:
that I separate, architecturally, the Artifact Repository, as a
separate service, from the build system itself.
> > and another for results, to support any arbitrary number of
> > artifacts/results
> > to a given build-instance.
>
> Good point.
>
> [...]
>
> So, things missing are:
>
> 1) bugzilla like comments (on build results only? or what else?)
> 2) artifact table / artifact type table
>
> Anything else you guys see missing?
Note: The results per build table (to support an arbirary number
of results per build) was a separate table from the artifact table.
In fact, at present in my schema, for a single build table entry,
there can be:
- any number of notes
- any number of artifacts
- any number of results
I separate artifacts (products of a build) from results (meta data
or things we know about or learn about the build products). A
result entry has one of four possible states in my schema: 1. unset,
2. pass, 3. warn, 4. fail (to which I map the obvious color in the
web presentation ;) -- extrapolating/generalizing that my sampling
of the world's traffic/semaphore lights extends to the rest of the
world; 7 countries on 4 continents - a good but small sample). And
unset = white.
Thanks for including me in the discussion. I look forward to more.
wade
