Opened 4 years ago

Last modified 2 years ago

#2622 new enhancement

[tracker] Better property support

Reported by: dustin Owned by:
Priority: major Milestone: 0.9.+
Version: Keywords: simple
Cc: Ben

Description (last modified by dustin)

Properties are currently omitted in many places in the Data API. Come up wiht a consistent way to represent properties (perhaps by adding a 'propertyset' rtype, flexible enough to serve for buildsets and builds).

The storage for the properties should also be determined carefully. A single blob containing all properties for a build set, build, etc., makes it difficult to query for builds with particular properties, which will surely be a common request.

Related:

  • #3075 - regarding the REST API for properties

Change History (5)

comment:1 Changed 3 years ago by sa2ajj

  • Cc Ben added

Ben, I think you looked at this.

What's your opinion about what needs to be done?

comment:2 Changed 3 years ago by dustin

  • Summary changed from [nine] More Properties to Better property support

Properties come from (from the docs):

  • global configuration
  • schedulers (including dynamic values from the force scheduler)
  • changes (assigned by the ChangeSource)
  • buildslave configuration
  • built-in per-build properties
  • builder config
  • previous steps

Tracing that through the process until a step starts:

  • A changesource creates a change and writes it to the DB
  • A scheduler reacts, creates a buildset and some buildrequests, and writes them to the DB -- with properties including those from the change. The properties are associated with the buildset, not the build requests
  • A builder claims the buildrequest, selects a buildslave, and starts a build. The build's initial properties are a combination of global configuration, buildset properties, buildslave properties, the builder's config, and built-in per-build properties.
  • As the build proceeds steps update the properties.

The properties land in the database in a few places:

  • change_properties -- properties for a change, created with the change
  • buildset_properties -- properties for a buildset, created with the buildset
  • build_properties -- properties for a single build; these are updated as necessary after each step

Note that there's some handling for properties "original" to a build, vs. properties as they stand at the end of the build.

All of this is in place in the database layer, and already broken out per property -- so it's not difficult to query the DB for, say, all builds with got_revision=1234.

But the Data API support lacks somewhat -- not all of these property sets are available at all via the Data API, and there are no messages when properties change. There's also no capability to query by properties.

comment:3 Changed 3 years ago by dustin

  • Summary changed from Better property support to [tracker] Better property support

comment:4 Changed 3 years ago by dustin

  • Description modified (diff)

comment:5 Changed 2 years ago by dustin

  • Milestone changed from 0.9.0 to 0.9.+
Note: See TracTickets for help on using tickets.