| Age | Commit message (Collapse) | Author |
|---|
|
This CL enables use of the cidb on builders run with --buildbot. In
particular:
- The cidb connection factory uses a cached cidb connection to avoid
creating duplicate connections per cbuildbot execution.
- A new stage, BuildStart is added, which is the first stage to run and
which inserts a build row into the database if appropriate.
- ReportBuildStart is renamed to BuildReexecutionFinished for clarity.
- UploadMetadata is extended to also update the build row in the
database.
- Calls to RecordCLAction are accompanied by a CL action database
insert.
- ReportStage calls FinishBuild and writes the final build status to
the database.
BUG=chromium:387755
TEST=cidb_integration_test;
remote trybots with --buildbot --debug, verified by inspecting database
that expected data is written there.
Change-Id: Ia2d9d355a744cafda0ade851be141519c56093d8
Reviewed-on: https://chromium-review.googlesource.com/211648
Reviewed-by: Aviv Keshet <akeshet@chromium.org>
Commit-Queue: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
|
|
Prior to this CL, writing an empty board dictionary to metadata would
not actually result in an entry for that board being retained.
BUG=None
TEST=New unit test
Change-Id: I2d44bf70ebbadb1115c006dfe8b8480be799967a
Reviewed-on: https://chromium-review.googlesource.com/213212
Tested-by: Aviv Keshet <akeshet@chromium.org>
Reviewed-by: Yu-Ju Hong <yjhong@chromium.org>
Commit-Queue: Aviv Keshet <akeshet@chromium.org>
|
|
This CL pulls the _GetChangeAsSmallDictionary method out of
CBuildbotMetadata and into its own module level helper function, and
creates the GetCLActionTuple helper function.
BUG=chromium:387755
TEST=Existing unit tests pass (verified that existing tests cover new
code)
Change-Id: Ibd09706dca591476f43975770799afda5225fb5c
Reviewed-on: https://chromium-review.googlesource.com/212344
Reviewed-by: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
Commit-Queue: Aviv Keshet <akeshet@chromium.org>
|
|
Prior to this change, when a metadata instance was created without a
multiprocess manager, it naively fell back on a multiprocess.RLock for
its subdict access lock, despite the fact that metadata is anyway not
multiprocess safe in the absence of a manager. The RLock however is
incompatible with BackgroundTaskRunner used in cidb_integration_test.
Instead, abandon any pretense of multiprocess safety in the absence of a
multiprocess manager, and use a dummy RLock which does nothing but is at
least compatible with BackgroundTaskRunner and thus doesn't break
cidb_integration_test.
BUG=chromium:401741
TEST=cidb_integration_test; unit tests
Change-Id: Ib44c088c80bd39abd5110e95a6b926d61a5dd1fc
Reviewed-on: https://chromium-review.googlesource.com/211478
Tested-by: Aviv Keshet <akeshet@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Queue: Aviv Keshet <akeshet@chromium.org>
|
|
This change adds a sub-dictionary of per-board metadata to the cbuildbot
metadata object. In dictionary representation, this will be stored in
the 'board-metadata' key, as a dict of dicts. Internally, this is stored
as a flattened multiprocess dict.
A new method is added to update per-board metadata.
BUG=chromium:309687
TEST=New unit tests added.
Change-Id: Ib65c4626e49be10238a6f2c0810aba1cbd3efc24
Reviewed-on: https://chromium-review.googlesource.com/210558
Reviewed-by: Aviv Keshet <akeshet@chromium.org>
Commit-Queue: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
|
|
We are using UpdateKeyDictWithDict to write version information to
metadata. This means we can potentially write to the same key from
multiple processes simultaneously.
This CL ensures that UpdateKeyDictWithDict is multiprocess safe by
adding a single multiprocess lock that must be acquired whenever
modifying a subdict.
BUG=None
TEST=New unit tests added, including one that tests multiprocess safety.
Verified that test fails prior to the lock being added.
Change-Id: Ia4ed34896b2a40cbd225c8edb3f8a266de0968f6
Reviewed-on: https://chromium-review.googlesource.com/210609
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-by: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
Commit-Queue: Aviv Keshet <akeshet@chromium.org>
|
|
This reverts commit a95e8538e5cbae05966eb35ab7fc60aecca30602.
Change-Id: I13227d343a1a9d38d01dbcbe3c9c3d431c2fbb8e
Reviewed-on: https://chromium-review.googlesource.com/210007
Reviewed-by: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
|
|
This code works by calling the firmware updater shellball with the -V option
which makes it print various version strings and a manifest of its contents.
That output is parsed, and the main and EC version strings are extracted. If
that file doesn't exist, for instance on boards like x86-generic, then the
fields are returned as None. That's then stored in the metadata json.
A unit test was added for the version extracting code.
BUG=chromium:309687
TEST=Ran run_tests. Ran a butteryfly tryjob and verified that firmware version
strings were in the metadata. Ran an x86-generic tryjob and verified that the
absence of firmware was reported. Ran an x86-mario and stumpy tryjob.
Change-Id: I459456578b79d8032d44b75a6012231a5e1328e2
Reviewed-on: https://chromium-review.googlesource.com/209940
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
|
|
Currently we track whether a builder succeeds by trying to parse the
list of stages that passed and failed. This is somewhat error prone, as
shown in Bug 393600.
An example case where the old logic can fail is in a grouped builder and
the first board fails in BuildPackages. In this case, subsequent boards
have no failed stages, and they are incorrectly marked as successful.
To solve this more accurately, we now instead set a variable when a board
passes, and otherwise assume that the board failed. This approach is always
correct at determining whether a board passed, and simpler.
Note: In cases where a builder does not have any boards, or has child builders,
we fall back and instead just look at whether the entire build was successful.
BUG=chromium:393600
TEST=Run it.
TEST=Run lumpy-incremental-paladin and verify it's marked as successful.
Change-Id: I99582c6b37d263f7cadf9d57fe2354c3e6c854f3
Reviewed-on: https://chromium-review.googlesource.com/208256
Tested-by: David James <davidjames@chromium.org>
Reviewed-by: Yu-Ju Hong <yjhong@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
|
|
BUG=chromium:387755
TEST=See CL:207579
Change-Id: Ifd57db3be79f8b619d55f72116652fba9eb3e77c
Reviewed-on: https://chromium-review.googlesource.com/207576
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Yu-Ju Hong <yjhong@chromium.org>
Reviewed-by: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
Commit-Queue: Aviv Keshet <akeshet@chromium.org>
|
|
Currently, we calculate the false rejection rate as fails / pickups,
which isn't very intuitive and leads to misleading numbers:
False rejection rate for CQ: 18.1%
False rejection rate for Pre-CQ: 3.5%
Combined false rejection rate: 10.1% (?!)
Currently we only report the combined false rejection ratio, but when
you break it down into its components the above problem becomes more
obvious.
This problem has its root in our definition of the false rejection rate.
Currently, if 10 CLs are rejected 20 times but picked up 100 times,
the false rejection rate is 20%. Conversely, if the same CLs are
rejected 20 times but picked up 30 times, the false rejection rate is
67%. This doesn't make any sense intuitively -- in general, it's bad for
CLs to be rejected more often, and it's not good to have CQ runs that
don't submit any CLs (e.g. due to infra failures).
We implement a new formula for false rejection rate here:
fails / (fails + submissions)
With my patch, the false rejection ratio is instead reported as:
False rejection rate for CQ: 21.1%
False rejection rate for Pre-CQ: 3.0%
Combined false rejection rate: 23.0%
BUG=none
TEST=Unit test.
TEST=Run for past week.
Change-Id: Ib6a507aeafc0201b1d9c5c1af4ff872115648d41
Reviewed-on: https://chromium-review.googlesource.com/205413
Reviewed-by: David James <davidjames@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
|
|
Also, return a default None value for a property when it is missing from
the metadata.json, so that gather_builder_stats can process the line.
BUG=chromium:369748
TEST=`./gather_builder_stats --cq-master --past-day` when there are lots
of builds with missing build numbers. build numbers are correctly
inferred and script does not fail.
`./gather_builder_stats --cq-master --past-day --save` adds rows for
these metadata files with missing build numbers.
Change-Id: I5d64cc562ff1ae4dc243a0c9c93a3726ea591e02
Reviewed-on: https://chromium-review.googlesource.com/203678
Tested-by: Aviv Keshet <akeshet@chromium.org>
Reviewed-by: Yu-Ju Hong <yjhong@chromium.org>
Commit-Queue: Aviv Keshet <akeshet@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
|
|
- Rename cbuildbot_archive -> archive_lib.
- Rename cbuildbot_metadata -> metadata_lib.
BUG=none
TEST=All unit tests.
TEST=Full release trybot run.
TEST=Paladin trybot run.
Change-Id: If4e4a6307e38e4e83b7cd4ec3f502d45cac25e2d
Reviewed-on: https://chromium-review.googlesource.com/202629
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
|
