Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting
Sorry, I realized that I had missed to include the files used for oe-selftest that testing the store operation. Submitted v5 patches that added the required files for oe-selftest -r resultstooltests. http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278243.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278244.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278245.html -Original Message- From: Yeoh, Ee Peng Sent: Tuesday, January 22, 2019 5:45 PM To: Richard Purdie ; openembedded-core@lists.openembedded.org Cc: Burton, Ross ; Paul Eggleton Subject: RE: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting Hi Richard, After your recently sharing on pythonic, we had revised these scripts in hope to improve the code readability and ease of maintenance. Also new functionalities were developed following pythonic style. The latest patches are just submitted today at below URL. http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278240.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278238.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278239.html Changes compared to previous version: 1. Add new features, merge multiple testresults.json file & regression analysis for two specified testresults.json 2. Add selftest to test merge, store, report and regression functionalities 3. Revised code style to align with pythonic Regarding your questions below: 1. What target layout are we aiming for in the git repository? - Are we aiming for a directory per commit tested where all the test results for that commit are in the same json file? - A directory per commit, then a directory per type of test? or per test run? or ??? - Are branches used for each release series (master, thud, sumo etc?) Basically, the layout we'd use to import the autobuilder results for each master run for example remains unclear to me, or how we'd look up the status of a given commit. The target layout shall be a specific git branch for each commit tested, where the file directories shall be based on existing Autobuilder results archive (eg. assuming store command was executed inside Autobuilder machine that stored the testresults.json files and predefined directory), simply execute: $ resultstool store where source_dir was the top directory used by Autobuilder to archive all testresults.json file, git_branch was the QA cycle for current tested commit. The first instance to execute "resultstool store" will generate a git repository under // directory. To update files to be stored, simply execute $ resultstool store -d //. 2. The code doesn't support comparison of two sets of test results (which tests were added/removed? passed when previously failed? failed when previously passed?) Assuming results from a particular tested commit were merged into a single file (using existing "merge" functionality), user shall use the newly added "regression" functionality for comparing results status for two testresults.json files. Based on the configurations data for each result_id set, the comparison logic will select result with same configurations for comparison. More advance regression and automation can be developed from current code base. 3. The code also doesn't allow investigation of test report "subdata" like looking at the ptest results, comparing them to previous runs, showing the logs for passed/failed ptests. There is also the question of json build performance data. This was not supported as of now, this will need further enhancement. Please let me know if any questions and inputs. Thank you very much for your sharing and help! Thanks, Yeoh Ee Peng -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Monday, January 21, 2019 10:26 PM To: Yeoh, Ee Peng ; openembedded-core@lists.openembedded.org Cc: Burton, Ross ; Paul Eggleton Subject: Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting On Fri, 2019-01-04 at 14:46 +0800, Yeoh Ee Peng wrote: > These scripts were developed as an alternative testcase management > tool to Testopia. Using these scripts, user can manage the > testresults.json files generated by oeqa automated tests. Using the > "store" operation, user can store multiple groups of test result each > into individual git branch. Within each git branch, user can store > multiple testresults.json files under different directories (eg. > categorize directory by selftest-, runtime-- > ). > Then, using the "report" operation, user can view the test result > summary for all available testresults.json files being stored that > were grouped by directory and test configuration. > > This scripts depends on scri
Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting
Hi Richard, After your recently sharing on pythonic, we had revised these scripts in hope to improve the code readability and ease of maintenance. Also new functionalities were developed following pythonic style. The latest patches are just submitted today at below URL. http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278240.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278238.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278239.html Changes compared to previous version: 1. Add new features, merge multiple testresults.json file & regression analysis for two specified testresults.json 2. Add selftest to test merge, store, report and regression functionalities 3. Revised code style to align with pythonic Regarding your questions below: 1. What target layout are we aiming for in the git repository? - Are we aiming for a directory per commit tested where all the test results for that commit are in the same json file? - A directory per commit, then a directory per type of test? or per test run? or ??? - Are branches used for each release series (master, thud, sumo etc?) Basically, the layout we'd use to import the autobuilder results for each master run for example remains unclear to me, or how we'd look up the status of a given commit. The target layout shall be a specific git branch for each commit tested, where the file directories shall be based on existing Autobuilder results archive (eg. assuming store command was executed inside Autobuilder machine that stored the testresults.json files and predefined directory), simply execute: $ resultstool store where source_dir was the top directory used by Autobuilder to archive all testresults.json file, git_branch was the QA cycle for current tested commit. The first instance to execute "resultstool store" will generate a git repository under // directory. To update files to be stored, simply execute $ resultstool store -d //. 2. The code doesn't support comparison of two sets of test results (which tests were added/removed? passed when previously failed? failed when previously passed?) Assuming results from a particular tested commit were merged into a single file (using existing "merge" functionality), user shall use the newly added "regression" functionality for comparing results status for two testresults.json files. Based on the configurations data for each result_id set, the comparison logic will select result with same configurations for comparison. More advance regression and automation can be developed from current code base. 3. The code also doesn't allow investigation of test report "subdata" like looking at the ptest results, comparing them to previous runs, showing the logs for passed/failed ptests. There is also the question of json build performance data. This was not supported as of now, this will need further enhancement. Please let me know if any questions and inputs. Thank you very much for your sharing and help! Thanks, Yeoh Ee Peng -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Monday, January 21, 2019 10:26 PM To: Yeoh, Ee Peng ; openembedded-core@lists.openembedded.org Cc: Burton, Ross ; Paul Eggleton Subject: Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting On Fri, 2019-01-04 at 14:46 +0800, Yeoh Ee Peng wrote: > These scripts were developed as an alternative testcase management > tool to Testopia. Using these scripts, user can manage the > testresults.json files generated by oeqa automated tests. Using the > "store" operation, user can store multiple groups of test result each > into individual git branch. Within each git branch, user can store > multiple testresults.json files under different directories (eg. > categorize directory by selftest-, runtime-- > ). > Then, using the "report" operation, user can view the test result > summary for all available testresults.json files being stored that > were grouped by directory and test configuration. > > This scripts depends on scripts/oe-git-archive where it was facing > error if gitpython package was not installed. Refer to [YOCTO# 13082] > for more detail. Thanks for the patches. These are a lot more readable than the previous versions and the code quality is much better which in turn helped review! I experimented with the code a bit. I'm fine with the manual test execution piece of this, I do have some questions/concerns with the result storage/reporting piece though. What target layout are we aiming for in the git repository? - Are we aiming for a directory per commit tested where all the test results for that commit are in the same json file? - A directory per commit, then a directory per type of test? or per test run? or ??? -
Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting
On Fri, 2019-01-04 at 14:46 +0800, Yeoh Ee Peng wrote: > These scripts were developed as an alternative testcase management > tool to Testopia. Using these scripts, user can manage the > testresults.json files generated by oeqa automated tests. Using the > "store" operation, user can store multiple groups of test result each > into individual git branch. Within each git branch, user can store > multiple testresults.json files under different directories (eg. > categorize directory by selftest-, runtime-- > ). > Then, using the "report" operation, user can view the test result > summary for all available testresults.json files being stored that > were grouped by directory and test configuration. > > This scripts depends on scripts/oe-git-archive where it was > facing error if gitpython package was not installed. Refer to > [YOCTO# 13082] for more detail. Thanks for the patches. These are a lot more readable than the previous versions and the code quality is much better which in turn helped review! I experimented with the code a bit. I'm fine with the manual test execution piece of this, I do have some questions/concerns with the result storage/reporting piece though. What target layout are we aiming for in the git repository? - Are we aiming for a directory per commit tested where all the test results for that commit are in the same json file? - A directory per commit, then a directory per type of test? or per test run? or ??? - Are branches used for each release series (master, thud, sumo etc?) Basically, the layout we'd use to import the autobuilder results for each master run for example remains unclear to me, or how we'd look up the status of a given commit. The code doesn't support comparison of two sets of test results (which tests were added/removed? passed when previously failed? failed when previously passed?) The code also doesn't allow investigation of test report "subdata" like looking at the ptest results, comparing them to previous runs, showing the logs for passed/failed ptests. There is also the question of json build performance data. The idea behind this code is to give us a report which allows us to decide on the QA state of a given set of testreport data. I'm just not sure this patch set lets us do that, or gives us a path to allow us to do that either. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting
These scripts were developed as an alternative testcase management
tool to Testopia. Using these scripts, user can manage the
testresults.json files generated by oeqa automated tests. Using the
"store" operation, user can store multiple groups of test result each
into individual git branch. Within each git branch, user can store
multiple testresults.json files under different directories (eg.
categorize directory by selftest-, runtime--).
Then, using the "report" operation, user can view the test result
summary for all available testresults.json files being stored that
were grouped by directory and test configuration.
The "report" operation expect the testresults.json file to use the
json format below.
{
"": {
"configuration": {
"": "",
"": "",
...
"": "",
},
"result": {
"": {
"status": "",
"log": ""
},
"": {
"status": "",
"log": ""
},
...
"": {
"status": "",
"log": ""
},
}
},
...
"": {
"configuration": {
"": "",
"": "",
...
"": "",
},
"result": {
"": {
"status": "",
"log": ""
},
"": {
"status": "",
"log": ""
},
...
"": {
"status": "",
"log": ""
},
}
},
}
To use these scripts, first source oe environment, then run the
entry point script to look for help.
$ test-case-mgmt
To store test result from oeqa automated tests, execute the below
$ test-case-mgmt store
By default, test result will be stored at /testresults
To store test result from oeqa automated tests under a specific
directory, execute the below
$ test-case-mgmt store -s
To view test report, execute the below
$ test-case-mgmt view
This scripts depends on scripts/oe-git-archive where it was
facing error if gitpython package was not installed. Refer to
[YOCTO# 13082] for more detail.
[YOCTO# 12654]
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/testcasemgmt/__init__.py | 0
scripts/lib/testcasemgmt/gitstore.py | 172 +
scripts/lib/testcasemgmt/report.py | 136
scripts/lib/testcasemgmt/store.py | 40 +
.../template/test_report_full_text.txt | 33
scripts/test-case-mgmt | 96
6 files changed, 477 insertions(+)
create mode 100644 scripts/lib/testcasemgmt/__init__.py
create mode 100644 scripts/lib/testcasemgmt/gitstore.py
create mode 100644 scripts/lib/testcasemgmt/report.py
create mode 100644 scripts/lib/testcasemgmt/store.py
create mode 100644 scripts/lib/testcasemgmt/template/test_report_full_text.txt
create mode 100755 scripts/test-case-mgmt
diff --git a/scripts/lib/testcasemgmt/__init__.py
b/scripts/lib/testcasemgmt/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/scripts/lib/testcasemgmt/gitstore.py
b/scripts/lib/testcasemgmt/gitstore.py
new file mode 100644
index 000..19ff28f
--- /dev/null
+++ b/scripts/lib/testcasemgmt/gitstore.py
@@ -0,0 +1,172 @@
+# test case management tool - store test result & log to git repository
+#
+# Copyright (c) 2018, Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+# more details.
+#
+import tempfile
+import os
+import subprocess
+import shutil
+import scriptpath
+scriptpath.add_bitbake_lib_path()
+scriptpath.add_oe_lib_path()
+from oeqa.utils.git import GitRepo, GitError
+
+class GitStore(object):
+
+def __init__(self, git_dir, git_branch):
+self.git_dir = git_dir
+self.git_branch = git_branch
+
+def _git_init(self):
+return GitRepo(self.git_dir, is_topdir=True)
+
+def _run_git_cmd(self, repo, cmd):
+try:
+output = repo.run_cmd(cmd)
+return True, output
+except GitError:
+return False, None
+
+def check_if_git_dir_exist(self, logger):
+if not os.path.exists('%s/.git' % self.git_dir):
+logger.debug('Could not find destination git directory: %s' %
self.git_dir)
+return False
+logger.debug('Found destination git directory: %s' % self.git_dir)
+return True
+
+def checkout_git_dir(self, logger):
+repo = self._git_init()
+
