Codeticket Service

From Second Life Wiki
Jump to navigation Jump to search

Overview

The primary purpose of the codeticket service is to assign monotonically increasing integers mapping to changeset ids.

The service supports attaching arbitrary metadata to every ticket delivered. Through careful use of relations between metadata items, it is possible to track:

  • Changes contributing to a build
  • Dependencies between builds
  • Deltas between builds
  • Changes being merged into new repositories
  • Jira references used in commit comments
  • ... and a variety of other uses.

The shortest way to describe the codeticket service is as an "append only data store, where arbitrary metadata can be attached to primary data elements, including references to other primary data elements".

Data Elements

A typical software development project will use multiple repositories reflecting QA status and intended stability criteria. Most common is a model like this:

Codeticket01.png

Builds

Depending on the configuration of your continuous build system, some changesets will trigger builds. The codeticket service assigns these builds integers:

Codeticket02.png

Note that multiple builds may get the same build number if they are triggered by the same changeset. As changesets propagate to different repositories via the mercurial hg pull or hg push command, they may end up at the tip multiple times, thereby re-triggering a build from a different repository, but for the same content.

Another deliberate way to get multiple builds using the same changeset is platform builds. The Snowstorm Viewer, for example, is compiled on three different platforms, and all those builds will get the same build number.

Context Changesets

Not all changesets will trigger builds. Those changesets which do not match up to a build are called context changesets within the codeticket service:

Codeticket03.png

At every build, the Automated Build System is designed to traverse the revision graph, and to associate every context changeset which is not already associated to the build in progress.

The build is said to "include these changes".

Once the Automated Build System encounters a changeset that already is associated with a build, then that build will be associated with the current build.

The build is said to "include that build".

Traversal of the arc containing the changeset stops at that point, as the associated build will already have all the subsequent associations:

Codeticket04.png

Querying Codeticket

The codeticket service has a web UI which allows users to navigate the relationships created by the Automated Build System.

Note: the webUI is not publicly accessible.

To simplify the explanations, we will omit context changesets from the diagram, and use a real example from the snowstorm viewer builds:

Codeticket05.png

Note that it isn't a perfect minimal graph, since builds happen concurrently, and the information at the time of the build will practically never include the whole revision graph.

The web UI allows easy drilldown through the inclusion chains:

  • A build will display all builds directly included by that build;
  • A build will also display all context changesets directly included in that build;
  • A context changeset will allow a drilldown into all builds including that context changeset, either directly or indirectly.

Various entry points for traversal exist:

  • Builds by repository owner
  • Builds by repository name
  • Builds by tag
  • ...

Computing the Delta between Two Builds

Computing the delta between two builds is accomplished by first traversing all the ancestors of the "old" build and marking them as "included in old build": Codeticket07.png

Then traversal resumes at the "new" build. Any unmarked build will be marked as "included by new build". If a marked build is encountered, or if maximum traversal depth is reached, traversal stops:

Codeticket08.png


To avoid overwhelming the user with data, a check is made to see if the "included in old build" has been reached at least once. If not, the diff is not shown, as it is unlikely that the two builds are related.

Computing Builds Not In a Given Build

This starts the same way as the delta computation, except that we also register the repositories used when marking the "included in old build" nodes.

Traversal then resumes from the most recent build in every repository traversed so far: Codeticket11.png