Merge lp:~adeuring/juju-ci-tools/add-missing-results-files-to-s3 into lp:juju-ci-tools
Status: | Merged |
---|---|
Merged at revision: | 692 |
Proposed branch: | lp:~adeuring/juju-ci-tools/add-missing-results-files-to-s3 |
Merge into: | lp:juju-ci-tools |
Diff against target: |
189 lines (+148/-11) 3 files modified
add-missing-result-yaml-files.py (+135/-0) backup-to-s3.py (+2/-11) utility.py (+11/-0) |
To merge this branch: | bzr merge lp:~adeuring/juju-ci-tools/add-missing-results-files-to-s3 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Curtis Hovey (community) | code | Approve | |
Review via email: mp+236008@code.launchpad.net |
Description of the change
This branch adds a new script to check if the files stored in S3 for all test runs contain a file result.yaml or result.json.
Additionally it checks for existing files "result.
Being a bit paranoid, I added checks that the dat recorded in S3 matches that in the main state file (lines 92..111).
In a dry run of the script on my laptop the second check results in warnings for some revisions that the compared dictionaries do not match. Some details:
revision 1855
S3 file:
"complete_
state file:
"complete_
revision 1856:
S3 file
"result": {"status": "curse", "build": 1268}
state file:
result: {build: 1269, status: bless}
Somewhat worrying... But the S3 files for both revisions contain a final result, so the script will not change anything.
I'm a bit too tired to dive into the other failures; can do this tomorrow. But it makes probably sense to explicitly prevent changes to result files that show this type of inconsistency.
Thank you very much for this script. I have a question. I think this branch is really valuable and would like it merged quickly.
I am not surprised by divergent result informaiton. juju-reports didn't try to get revised results for many months. This also accounts for retries of tests that still failed.