From 21ea55a3b1a60c50f009a115ea4ff30fcc47c10c Mon Sep 17 00:00:00 2001 From: Cleber Rosa Date: Wed, 10 Jun 2015 11:00:52 -0300 Subject: [PATCH] doc review: move result specification to the Reference Section As this pretty much documents how Avocado saves the results, it's pretty much a reference document. The location of the job logs is pretty clear in the Getting Started section when the user runs their first tests, and it's pretty obvious even for 1st time users not even reading the documentation. If users want to understand more about it, or customize the location, the Reference Guide is indeed the place to go. Signed-off-by: Cleber Rosa --- docs/source/ReferenceGuide.rst | 117 +++++++++++++++++++++++++++ docs/source/ResultsSpecification.rst | 116 -------------------------- docs/source/index.rst | 1 - 3 files changed, 117 insertions(+), 117 deletions(-) delete mode 100644 docs/source/ResultsSpecification.rst diff --git a/docs/source/ReferenceGuide.rst b/docs/source/ReferenceGuide.rst index 0f6412c3..fae5bf82 100644 --- a/docs/source/ReferenceGuide.rst +++ b/docs/source/ReferenceGuide.rst @@ -107,4 +107,121 @@ diagram below shows how Avocado analyzes a file and decides what to do with it: .. figure:: diagram.png + +Results Specification +===================== + +On a machine that executed tests, job results are available under +``[job-results]/job-[timestamp]-[short job ID]``, where ``logdir`` is the configured Avocado +logs directory (see the data dir plugin), and the directory name includes +a timestamp, such as ``job-2014-08-12T15.44-565e8de``. A typical +results directory structure can be seen below :: + + $HOME/avocado/job-results/job-2014-08-13T00.45-4a92bc0/ + ├── id + ├── job.log + ├── results.json + ├── results.xml + ├── sysinfo + │   ├── post + │   │   ├── brctl_show + │   │   ├── cmdline + │   │   ├── cpuinfo + │   │   ├── current_clocksource + │   │   ├── df_-mP + │   │   ├── dmesg_-c + │   │   ├── dmidecode + │   │   ├── fdisk_-l + │   │   ├── gcc_--version + │   │   ├── hostname + │   │   ├── ifconfig_-a + │   │   ├── interrupts + │   │   ├── ip_link + │   │   ├── ld_--version + │   │   ├── lscpu + │   │   ├── lspci_-vvnn + │   │   ├── meminfo + │   │   ├── modules + │   │   ├── mount + │   │   ├── mounts + │   │   ├── numactl_--hardware_show + │   │   ├── partitions + │   │   ├── scaling_governor + │   │   ├── uname_-a + │   │   ├── uptime + │   │   └── version + │   └── pre + │   ├── brctl_show + │   ├── cmdline + │   ├── cpuinfo + │   ├── current_clocksource + │   ├── df_-mP + │   ├── dmesg_-c + │   ├── dmidecode + │   ├── fdisk_-l + │   ├── gcc_--version + │   ├── hostname + │   ├── ifconfig_-a + │   ├── interrupts + │   ├── ip_link + │   ├── ld_--version + │   ├── lscpu + │   ├── lspci_-vvnn + │   ├── meminfo + │   ├── modules + │   ├── mount + │   ├── mounts + │   ├── numactl_--hardware_show + │   ├── partitions + │   ├── scaling_governor + │   ├── uname_-a + │   ├── uptime + │   └── version + └── test-results + └── tests + ├── sleeptest.py.long + │   ├── data + │   ├── debug.log + │   └── sysinfo + │   ├── post + │   └── pre + ├── sleeptest.py.medium + │   ├── data + │   ├── debug.log + │   └── sysinfo + │   ├── post + │   └── pre + └── sleeptest.py.short + ├── data + ├── debug.log + └── sysinfo + ├── post + └── pre + + 20 directories, 59 files + + +From what you can see, the results dir has: + +1) A human readable ``id`` in the top level, with the job SHA1. +2) A human readable ``job.log`` in the top level, with human readable logs of + the task +3) A machine readable ``results.xml`` in the top level, with a summary of the + job information in xUnit format. +4) A top level ``sysinfo`` dir, with sub directories ``pre`` and ``post``, that store + sysinfo files pre job and post job, respectively. +5) Subdirectory ``test-results``, that contains a number of subdirectories + (tagged testnames). Those tagged testnames represent instances of test + execution results. + +Test execution instances specification +-------------------------------------- + +The instances should have: + +1) A top level human readable ``test.log``, with test debug information +2) A ``sysinfo`` subdir, with sub directories ``pre`` and ``post``, that store + sysinfo files pre test and post test, respectively. +3) A ``data`` subdir, where the test can output a number of files if necessary. + .. [#f1] Avocado plugins can introduce additional test types. diff --git a/docs/source/ResultsSpecification.rst b/docs/source/ResultsSpecification.rst deleted file mode 100644 index d11f83d5..00000000 --- a/docs/source/ResultsSpecification.rst +++ /dev/null @@ -1,116 +0,0 @@ -===================== -Results Specification -===================== - -On a machine that executed tests, job results are available under -``[job-results]/job-[timestamp]-[short job ID]``, where ``logdir`` is the configured Avocado -logs directory (see the data dir plugin), and the directory name includes -a timestamp, such as ``job-2014-08-12T15.44-565e8de``. A typical -results directory structure can be seen below :: - - $HOME/avocado/job-results/job-2014-08-13T00.45-4a92bc0/ - ├── id - ├── job.log - ├── results.json - ├── results.xml - ├── sysinfo - │   ├── post - │   │   ├── brctl_show - │   │   ├── cmdline - │   │   ├── cpuinfo - │   │   ├── current_clocksource - │   │   ├── df_-mP - │   │   ├── dmesg_-c - │   │   ├── dmidecode - │   │   ├── fdisk_-l - │   │   ├── gcc_--version - │   │   ├── hostname - │   │   ├── ifconfig_-a - │   │   ├── interrupts - │   │   ├── ip_link - │   │   ├── ld_--version - │   │   ├── lscpu - │   │   ├── lspci_-vvnn - │   │   ├── meminfo - │   │   ├── modules - │   │   ├── mount - │   │   ├── mounts - │   │   ├── numactl_--hardware_show - │   │   ├── partitions - │   │   ├── scaling_governor - │   │   ├── uname_-a - │   │   ├── uptime - │   │   └── version - │   └── pre - │   ├── brctl_show - │   ├── cmdline - │   ├── cpuinfo - │   ├── current_clocksource - │   ├── df_-mP - │   ├── dmesg_-c - │   ├── dmidecode - │   ├── fdisk_-l - │   ├── gcc_--version - │   ├── hostname - │   ├── ifconfig_-a - │   ├── interrupts - │   ├── ip_link - │   ├── ld_--version - │   ├── lscpu - │   ├── lspci_-vvnn - │   ├── meminfo - │   ├── modules - │   ├── mount - │   ├── mounts - │   ├── numactl_--hardware_show - │   ├── partitions - │   ├── scaling_governor - │   ├── uname_-a - │   ├── uptime - │   └── version - └── test-results - └── tests - ├── sleeptest.py.long - │   ├── data - │   ├── debug.log - │   └── sysinfo - │   ├── post - │   └── pre - ├── sleeptest.py.medium - │   ├── data - │   ├── debug.log - │   └── sysinfo - │   ├── post - │   └── pre - └── sleeptest.py.short - ├── data - ├── debug.log - └── sysinfo - ├── post - └── pre - - 20 directories, 59 files - - -From what you can see, the results dir has: - -1) A human readable ``id`` in the top level, with the job SHA1. -2) A human readable ``job.log`` in the top level, with human readable logs of - the task -3) A machine readable ``results.xml`` in the top level, with a summary of the - job information in xUnit format. -4) A top level ``sysinfo`` dir, with sub directories ``pre`` and ``post``, that store - sysinfo files pre job and post job, respectively. -5) Subdirectory ``test-results``, that contains a number of subdirectories - (tagged testnames). Those tagged testnames represent instances of test - execution results. - -Test execution instances specification -====================================== - -The instances should have: - -1) A top level human readable ``test.log``, with test debug information -2) A ``sysinfo`` subdir, with sub directories ``pre`` and ``post``, that store - sysinfo files pre test and post test, respectively. -3) A ``data`` subdir, where the test can output a number of files if necessary. diff --git a/docs/source/index.rst b/docs/source/index.rst index 8a764276..d9014cad 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -11,7 +11,6 @@ Contents: GetStartedGuide WritingTests Configuration - ResultsSpecification MultiplexConfig Plugins OutputPlugins -- GitLab