[Patchew-devel] [PATCH v2 00/10] Store results in database

Paolo Bonzini posted 10 patches 5 years, 10 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/patchew-ci tags/patchew/20180531100334.2249-1-pbonzini@redhat.com
There is a newer version of this series
api/blobs.py                                  |  38 +++
api/migrations/0027_auto_20180521_0152.py     |  61 +++++
api/migrations/0028_populate_git_results.py   | 104 +++++++++
.../0029_populate_testing_results.py          | 220 ++++++++++++++++++
api/migrations/0030_deblob_properties.py      |  34 +++
api/migrations/0031_auto_20180520_1654.py     |  34 +++
api/migrations/__init__.py                    |  47 ++++
api/models.py                                 | 219 ++++++++++-------
api/rest.py                                   |  67 ++----
mods/git.py                                   | 137 +++++------
mods/testing.py                               | 215 ++++++++---------
patchew/logviewer.py                          |  14 +-
requirements.txt                              |   2 +-
tests/test_git.py                             |  34 +--
tests/test_testing.py                         |  53 +++--
www/views.py                                  |  17 +-
16 files changed, 912 insertions(+), 384 deletions(-)
create mode 100644 api/blobs.py
create mode 100644 api/migrations/0027_auto_20180521_0152.py
create mode 100644 api/migrations/0028_populate_git_results.py
create mode 100644 api/migrations/0029_populate_testing_results.py
create mode 100644 api/migrations/0030_deblob_properties.py
create mode 100644 api/migrations/0031_auto_20180520_1654.py
[Patchew-devel] [PATCH v2 00/10] Store results in database
Posted by Paolo Bonzini 5 years, 10 months ago
The main changes here, compared to the RFC, are 1) switching to multi-table
inheritance, and 2) splitting the log entry into a separate table for
efficiency.

Because of the switch to multi-table inheritance, there were a couple of
cascading changes.  The first is that result.obj is now available for
results (it is not anymore a field; it is a polymorphic method defined by
the subclasses ProjectResult and MessageResult).  The second is the switch
of jsonfield to a fork, jsonfield2, which has been ported to work with
modern Django - it supports Django 2.x when we want to go there, and
especially it fixes an issue with multi-table inheritance.  You'll have
to destroy your virtual environment and rerun scripts/developer-setup
because of this.

The first three patches of the RFC series are already in master.

Still not tested as much as one should test such a big change, but
it is moving...  One thing I'm curious about, that I noticed while
writing this series: what prevents multiple testers from picking the
same project-based testing job?

Paolo

Paolo Bonzini (10):
  models: move Result log_url from constructor to renderer
  models: extract blobs functions to a separate file
  update jsonfield to 3.0.x
  models: create Result model
  git: switch to Result model
  testing: track changes to the set of tests
  testing: switch to Result model
  complete switch to database-based Results
  models: convert MessageProperty and ProjectProperty to JSONField
  logviewer: let subclasses return a Result

 api/blobs.py                                  |  38 +++
 api/migrations/0027_auto_20180521_0152.py     |  61 +++++
 api/migrations/0028_populate_git_results.py   | 104 +++++++++
 .../0029_populate_testing_results.py          | 220 ++++++++++++++++++
 api/migrations/0030_deblob_properties.py      |  34 +++
 api/migrations/0031_auto_20180520_1654.py     |  34 +++
 api/migrations/__init__.py                    |  47 ++++
 api/models.py                                 | 219 ++++++++++-------
 api/rest.py                                   |  67 ++----
 mods/git.py                                   | 137 +++++------
 mods/testing.py                               | 215 ++++++++---------
 patchew/logviewer.py                          |  14 +-
 requirements.txt                              |   2 +-
 tests/test_git.py                             |  34 +--
 tests/test_testing.py                         |  53 +++--
 www/views.py                                  |  17 +-
 16 files changed, 912 insertions(+), 384 deletions(-)
 create mode 100644 api/blobs.py
 create mode 100644 api/migrations/0027_auto_20180521_0152.py
 create mode 100644 api/migrations/0028_populate_git_results.py
 create mode 100644 api/migrations/0029_populate_testing_results.py
 create mode 100644 api/migrations/0030_deblob_properties.py
 create mode 100644 api/migrations/0031_auto_20180520_1654.py

-- 
2.17.0

_______________________________________________
Patchew-devel mailing list
Patchew-devel@redhat.com
https://www.redhat.com/mailman/listinfo/patchew-devel
Re: [Patchew-devel] [PATCH v2 00/10] Store results in database
Posted by Fam Zheng 5 years, 10 months ago
On Thu, 05/31 12:03, Paolo Bonzini wrote:
> what prevents multiple testers from picking the
> same project-based testing job?

Good question. Symmetric testers are not very thoroughly designed and this
indeed is looser than it should be. We will fix them as we go. I'm not happy
with the 'testing.start-time' filtering in _find_series_test(), because if
multiple testers are idle, they still do duplicated work and possibly generate
redundant error reports.  But that could at least be replicated to project tests
too.

Fam

_______________________________________________
Patchew-devel mailing list
Patchew-devel@redhat.com
https://www.redhat.com/mailman/listinfo/patchew-devel