[Findit] Add a sub-pipeline to detect first-known failure.

appengine/findit/model/base_model.py

Index: appengine/findit/model/base_model.py
diff --git a/appengine/findit/model/base_model.py b/appengine/findit/model/base_model.py
new file mode 100644
index 0000000000000000000000000000000000000000..3f4c013ce3ebd12d18dd299187422f7544e54070
--- /dev/null
+++ b/appengine/findit/model/base_model.py
@@ -0,0 +1,27 @@
+# Copyright (c) 2014 The Chromium Authors. All rights reserved.

[qyearsley, 2015/01/07 06:59:46]

Note, the "(c)" isn't necessary, and can be removed from the header in all
files.

http://www.chromium.org/developers/coding-style#TOC-File-headers

[stgao, 2015/01/09 01:28:23]

Good catch.
Done for files in this CL.
For other files in Findit, I will do it in a separate CL.

+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+from google.appengine.ext import ndb
+
+
+class BaseModel(ndb.Model):  # pragma: no cover
+  """A base class to provide computed properties from the key.

[qyearsley, 2015/01/07 06:59:46]

This looks like a good idea. Possible alternative names: BaseBuildModel or
BuildBaseModel (BaseModel should be fine too).

Currently the two subclasses are Build and BuildAnalysis, right? But if you had
any other build-specific models then they could also have similar keys.


Note about one problem we ran into with the perf dashboard: all entities under
one top-level key (in this case, master name) are part of one "entity group",
and there's a limit to the number of puts per second within one entity group.

This was a problem for the dashboard only because points were added at a high
rate. If there's ever going to be a time when entities are added at a high rate,
then you could make your model so that they're not nested. For the dashboard
points, we switched to keys like:
  ndb.Key('KindName', 'master/bot/test/specific/path', 'Row', 289083)

[stgao, 2015/01/09 01:28:23]

I like BaseBuildModel better.
Done.
Yes, this base class is for models Step/Test.
Good catch!
For scaling, we'd better "keep entity groups small"
(https://cloud.google.com/appengine/articles/scaling/contention).

I'd switch to keys like:
   ndb.Key('Build', 'master/builder/build', 'optional_KindName', optional_id,
...)

+
+  The computed properties are master name, builder name, and build number.
+  Subclasses should set its key as:
+    ndb.Key('KindName', master_name, 'KindName', builder_name,
+            'KindName', build_number, 'Optional_KindName', optional_id, ...)
+  """
+
+  @ndb.ComputedProperty
+  def master_name(self):
+    return self.key.pairs()[0][1]
+
+  @ndb.ComputedProperty
+  def builder_name(self):
+    return self.key.pairs()[1][1]
+
+  @ndb.ComputedProperty
+  def build_number(self):
+    return self.key.pairs()[2][1]