Confirmed users
353
edits
EngineeringProductivity/Projects/Treeherder: Difference between revisions
Jump to navigation
Jump to search
EngineeringProductivity/Projects/Treeherder (view source)
Revision as of 22:52, 20 December 2012
, 20 December 2012→We Need A Data Model
| Line 45: | Line 45: | ||
After examining TBPL and it's relationship to Buildbot and mercurial it's unclear that TBPL should be the "source of truth" for build/branch/revision and os/platform/test nomenclature or for obtaining mappings between build and push data. The original sources of that information are the build system (Buildbot or any other automated build process) and the source code repository (mercurial or git). There are a variety of third party applications: TBPL, orange factor, graph server, talos, datazilla, go faster etc... (the number continues to grow!) that make use of subsets of this information by parsing build logs (many times over and in a multitude of different ways) or using related services/data. Each of these applications, including TBPL, attempts to represent the relationship (or subset of) between a build/push/branch/revision and os/platform/test in its own way with its own implementation of a "data model". These data models often maintain multiple methods of mapping between different application nomenclature versions. Some examples would include Buildbot->TBPL->OrangeFactor or Talos->TBPL->Graph Server. This makes it impossible to add new automation without breaking an armada of downstream applications. | After examining TBPL and it's relationship to Buildbot and mercurial it's unclear that TBPL should be the "source of truth" for build/branch/revision and os/platform/test nomenclature or for obtaining mappings between build and push data. The original sources of that information are the build system (Buildbot or any other automated build process) and the source code repository (mercurial or git). There are a variety of third party applications: TBPL, orange factor, graph server, talos, datazilla, go faster etc... (the number continues to grow!) that make use of subsets of this information by parsing build logs (many times over and in a multitude of different ways) or using related services/data. Each of these applications, including TBPL, attempts to represent the relationship (or subset of) between a build/push/branch/revision and os/platform/test in its own way with its own implementation of a "data model". These data models often maintain multiple methods of mapping between different application nomenclature versions. Some examples would include Buildbot->TBPL->OrangeFactor or Talos->TBPL->Graph Server. This makes it impossible to add new automation without breaking an armada of downstream applications. | ||
We need a data model definition for a build, push, branch, revision, os, platform, and test that describes each entities attributes and the relationship between them. With that in hand we could start identifying where the root source of the information is, and at what point in the lifecycle of a source code push and Buildbot build, that it's available. Some of this information might require accessing both a build system and a related source code repository for services and data. | We need a data model definition for a product, build, push, branch, revision, os, platform, and test that describes each entities attributes and the relationship between them. With that in hand we could start identifying where the root source of the information is, and at what point in the lifecycle of a source code push and Buildbot build, that it's available. Some of this information might require accessing both a build system and a related source code repository for services and data. | ||
Regardless of the data model's physical representation, building a proxy web service that would provide an API to the data model by digesting the various services/data from their original sources: buildbot, mercurial, git etc... would be a big step forward. TBPL would be a consumer of this service like any other third party application. This would allow us to decouple from Buildbot and serve B2G, Fennec, and Firefox data in a systematic manner. It would also allow us to define a single source of nomenclature for a build, push, branch, revision, os, platform, and test. | Regardless of the data model's physical representation, building a proxy web service that would provide an API to the data model by digesting the various services/data from their original sources: buildbot, mercurial, git etc... would be a big step forward. TBPL would be a consumer of this service like any other third party application. This would allow us to decouple from Buildbot and serve B2G, Fennec, and Firefox data in a systematic manner. It would also allow us to define a single source of nomenclature for a build, push, branch, revision, os, platform, and test. | ||