Megatest

Megatest. See the script installall.sch in the utils directory of the
distribution for a mostly automated way to install everything needed
for building Megatest on Linux.

footnote:[An example footnote.]
indexterm:[Example index entry]



And now for something completely different: ((monkeys)), lions and
tigers (Bengal and Siberian) using the alternative syntax index
entries.
(((Big cats,Lions)))
(((Big cats,Tigers,Bengal Tiger)))
(((Big cats,Tigers,Siberian Tiger)))
Note that multi-entry terms generate separate index entries.

Here are a couple of image examples: an image:images/smallnew.png[]
example inline image followed by an example block image:

.Tiger block image
image::images/tiger.png[Tiger image]

Followed by an example table:

.An example table
[width="60%",options="header"]
|==============================================
| Option          | Description
| -a 'USER GROUP' | Add 'USER' to 'GROUP'.
| -R 'GROUP'      | Disables access to 'GROUP'.
|==============================================

.An example example
===============================================
Lorum ipum...
===============================================

[[X1]]
Sub-section with Anchor
~~~~~~~~~~~~~~~~~~~~~~~
Sub-section at level 2.

Chapter Sub-section
^^^^^^^^^^^^^^^^^^^
Sub-section at level 3.

Chapter Sub-section
+++++++++++++++++++
Sub-section at level 4.

This is the maximum sub-section depth supported by the distributed
AsciiDoc configuration.
footnote:[A second example footnote.]


The Second Chapter
------------------
An example link to anchor at start of the <<X1,first sub-section>>.
indexterm:[Second example index entry]

An example link to a bibliography entry <<taoup>>.


// 
// 
// And now for something completely different: ((monkeys)), lions and
// tigers (Bengal and Siberian) using the alternative syntax index
// entries.
// (((Big cats,Lions)))
// (((Big cats,Tigers,Bengal Tiger)))
// (((Big cats,Tigers,Siberian Tiger)))
// Note that multi-entry terms generate separate index entries.
// 
// Here are a couple of image examples: an image:images/smallnew.png[]
// example inline image followed by an example block image:
// 
// .Tiger block image
// image::images/tiger.png[Tiger image]
// 
// Followed by an example table:
// 
// .An example table
// [width="60%",options="header"]
// |==============================================
// | Option          | Description
// | -a 'USER GROUP' | Add 'USER' to 'GROUP'.
// | -R 'GROUP'      | Disables access to 'GROUP'.
// |==============================================
// 
// .An example example
// ===============================================
// Lorum ipum...
// ===============================================
// 
// [[X1]]
// Sub-section with Anchor
// ~~~~~~~~~~~~~~~~~~~~~~~
// Sub-section at level 2.
// 
// Chapter Sub-section
// ^^^^^^^^^^^^^^^^^^^
// Sub-section at level 3.
// 
// Chapter Sub-section
// +++++++++++++++++++
// Sub-section at level 4.
// 
// This is the maximum sub-section depth supported by the distributed
// AsciiDoc configuration.
// footnote:[A second example footnote.]
// 
// 
// The Second Chapter
// ------------------
// An example link to anchor at start of the <<X1,first sub-section>>.
// indexterm:[Second example index entry]
// 
// An example link to a bibliography entry <<taoup>>.
// 
// 

----------------

Examining The Environment
~~~~~~~~~~~~~~~~~~~~~~~~~

During Config File Processing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It is often helpful to know the content of variables in various
contexts as Megatest does the actions needed to run your tests. A handy technique is to force the startup of an xterm in the context being examined.

For example, if an item list is not being generated as expected you
can inject the startup of an xterm as if it were an item:

.Original items table
-----------------
[items]
CELLNAME [system getcellname.sh]
-----------------

.Items table modified for debug
-----------------
[items]
DEBUG [system xterm]
CELLNAME [system getcellnames.sh]
-----------------

When this test is run an xterm will pop up. In that xterm the
environment is exactly that in which the script "getcellnames.sh"
would run. You can now debug the script to find out why it isn't
working as expected.

Organising Your Tests and Tasks
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The default location "tests" for storing tests can be extended by
adding to your tests-paths section.

----------------------------
[misc]
parent #{shell dirname $(readlink -f .)}

[tests-paths]
1 #{get misc parent}/simplerun/tests
----------------------------

-------------------
[setup]
The above example shows how you can use addition sections in your
config file to do complex processing. By putting results of relatively
slow operations into variables the processing of your configs can be
kept fast.
-------------------

The runscript method is a brute force way to run scripts where the
user is responsible for setting STATE and STATUS
Alternative Method for Running your Job Script
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.Directly running job in testconfig
-------------------
[setup]
runscript main.csh
-------------------

The runscript method is essentially a brute force way to run scripts where the
user is responsible for setting STATE and STATUS and managing the details of running a test. 

Debugging Server Problems
~~~~~~~~~~~~~~~~~~~~~~~~~

Some handy Unix commands to track down issues with servers not
communicating with your test manager processes. Please put in tickets
at https://www.kiatoa.com/fossils/megatest if you have problems with
servers getting stuck.

----------------
sudo lsof -i
sudo netstat -lptu
sudo netstat -tulpn
----------------

<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="generator" content="AsciiDoc 8.6.7">
<meta name="generator" content="AsciiDoc 8.6.9">
<title>The Megatest Users Manual</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */

/* Default font. */
body {
  font-family: Georgia,serif;

ul, ol, li > p {
  margin-top: 0;
}
ul > li     { color: #aaa; }
ul > li > * { color: black; }

pre {
.monospaced, code, pre {
  font-family: "Courier New", Courier, monospace;
  font-size: inherit;
  color: navy;
  padding: 0;
  margin: 0;
}
pre {
  white-space: pre-wrap;
}

#author {
  color: #527bbd;
  font-weight: bold;
  font-size: 1.1em;
}
#email {

div.exampleblock > div.content {
  border-left: 3px solid #dddddd;
  padding-left: 0.5em;
}

div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; }
span.image img { border-style: none; vertical-align: text-bottom; }
a.image:visited { color: white; }

dl {
  margin-top: 0.8em;
  margin-bottom: 0.8em;
}
dt {

/*
 * xhtml11 specific
 *
 * */

tt {
  font-family: "Courier New", Courier, monospace;
  font-size: inherit;
  color: navy;
}

div.tableblock {
  margin-top: 1.0em;
  margin-bottom: 1.5em;
}
div.tableblock > table {
  border: 3px solid #527bbd;
}

/*
 * html5 specific
 *
 * */

.monospaced {
  font-family: "Courier New", Courier, monospace;
  font-size: inherit;
  color: navy;
}

table.tableblock {
  margin-top: 1.0em;
  margin-bottom: 1.5em;
}
thead, p.tableblock.header {
  font-weight: bold;
  color: #527bbd;

body.manpage div.sectionbody {
  margin-left: 3em;
}

@media print {
  body.manpage div#toc { display: none; }
}


@media screen {
  body {
    max-width: 50em; /* approximately 80 characters wide */
    margin-left: 16em;
  }

  #toc {

<div class="paragraph"><p>Note 1: This road-map is tentative and subject to change without notice.</p></div>
<div class="paragraph"><p>Note 2: Starting over. Old plan is commented out.</p></div>
<div class="sect1">
<h2 id="_current_items">Current Items</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_ww05_migrate_to_inmem_db">ww05 - migrate to inmem-db</h3>
<div class="paragraph"><p>Keep as much the same as possible. Add internal reference to almost
eliminate contention on db(s).</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
Add internal reference db
Switch to inmem db with fast sync to on disk db&#8217;s [DONE]
</p>
</li>
<li>
<p>
Verify that actions are accessing correct db
Server polls tasks table for next action
</p>
<div class="olist loweralpha"><ol class="loweralpha">
<li>
<p>
-runtests  - inmem
Task table used for tracking runner process [DONE]
</p>
</li>
<li>
<p>
-list-runs - local (but not megatest.db)
</p>
</li>
<li>
<p>
dashboard  - local (but not megatest.db)
</p>
</li>
</ol></div>
</li>
<li>
<p>
Mirror db to /var/tmp&#8230;
</p>
</li>
<li>
<p>
Dashboard read db from per-run db.
</p>
</li>
<li>
<p>
Dashboard read db from /var/tmp
</p>
</li>
<li>
<p>
Runs register in tasks table in monitor.db
Task table used for jobs to run
</p>
</li>
<li>
<p>
Server polls tasks table for next action (in addition?)
Task table used for queueing runner actions (remove runs, cleanRunExecute, etc)
</p>
</li>
<li>
<p>
Change run loop to execute in server, triggered by call to polling of tasks table
</p>
</ol></div>
</li>
</ol></div>
</div>
</div>
</div>
<h1 id="_getting_started">Getting Started</h1>
<div class="openblock">

<div class="sect2">
<h3 id="_dependencies">Dependencies</h3>
<div class="paragraph"><p>Chicken scheme and a number of "eggs" are required for building
Megatest. See the script installall.sch in the utils directory of the
distribution for a mostly automated way to install everything needed
for building Megatest on Linux.</p></div>
<div class="paragraph"><p><span class="footnote"><br>[An example footnote.]<br></span></p></div>
<div class="paragraph"><p>And now for something completely different: monkeys, lions and
tigers (Bengal and Siberian) using the alternative syntax index
entries.



Note that multi-entry terms generate separate index entries.</p></div>
<div class="paragraph"><p>Here are a couple of image examples: an <span class="image">
<img src="images/smallnew.png" alt="images/smallnew.png">
</span>
example inline image followed by an example block image:</p></div>
<div class="imageblock">
<div class="content">
<img src="images/tiger.png" alt="Tiger image">
</div>
<div class="title">Figure 1. Tiger block image</div>
</div>
<div class="paragraph"><p>Followed by an example table:</p></div>
<table class="tableblock frame-all grid-all"
style="
width:60%;
">
<caption class="title">Table 1. An example table</caption>
<col style="width:50%;">
<col style="width:50%;">
<thead>
<tr>
<th class="tableblock halign-left valign-top" > Option          </th>
<th class="tableblock halign-left valign-top" > Description</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top" ><p class="tableblock">-a <em>USER GROUP</em></p></td>
<td class="tableblock halign-left valign-top" ><p class="tableblock">Add <em>USER</em> to <em>GROUP</em>.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top" ><p class="tableblock">-R <em>GROUP</em></p></td>
<td class="tableblock halign-left valign-top" ><p class="tableblock">Disables access to <em>GROUP</em>.</p></td>
</tr>
</tbody>
</table>
<div class="exampleblock">
<div class="title">Example 1. An example example</div>
<div class="content">
<div class="paragraph"><p>Lorum ipum&#8230;</p></div>
</div></div>
</div>
<div class="sect2">
<h3 id="X1">Sub-section with Anchor</h3>
<div class="paragraph"><p>Sub-section at level 2.</p></div>
<div class="sect3">
<h4 id="_chapter_sub_section">Chapter Sub-section</h4>
<div class="paragraph"><p>Sub-section at level 3.</p></div>
<div class="sect4">
<h5 id="_chapter_sub_section_2">Chapter Sub-section</h5>
<div class="paragraph"><p>Sub-section at level 4.</p></div>
<div class="paragraph"><p>This is the maximum sub-section depth supported by the distributed
AsciiDoc configuration.
<span class="footnote"><br>[A second example footnote.]<br></span></p></div>
</div>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_the_second_chapter">The Second Chapter</h2>
<div class="sectionbody">
<div class="paragraph"><p>An example link to anchor at start of the <a href="#X1">first sub-section</a>.</p></div>
<div class="paragraph"><p>An example link to a bibliography entry <a href="#taoup">[taoup]</a>.</p></div>
</div>
</div>
<h1 id="_writing_tests">Writing Tests</h1>
<div class="sect1">
<h2 id="_the_first_chapter_of_the_second_part">The First Chapter of the Second Part</h2>
<h2 id="_creating_a_new_test">Creating a new Test</h2>
<div class="sectionbody">
<div class="paragraph"><p>The following steps will add a test "yourtestname" to your testsuite. This assumes
starting from a directory where you already have a megatest.config and
runconfigs.config.</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
Create a directory tests/yourtestname
</p>
</li>
<li>
<p>
Create a file tests/yourtestname/testconfig
</p>
</li>
</ol></div>
<div class="listingblock">
<div class="title">Contents of minimal testconfig</div>
<div class="content monospaced">
<pre>[ezsteps]
stepname1 stepname.sh
<div class="paragraph"><p>Chapters grouped into book parts are at level 1 and can contain
sub-sections.</p></div>

# test_meta is a section for storing additional data on your test
[test_meta]
author myname
owner  myname
description An example test
reviewed never</pre>
</div></div>
<div class="paragraph"><p>This test runs a single step called "stepname1" which runs a script
"stepname.sh". Note that although it is common to put the actions
needed for a test step into a script it is not necessary.</p></div>
</div>
</div>
<h1 id="_how_to_do_things">How To Do Things</h1>
<div class="sect1">
<h2 id="_tricks">Tricks</h2>
<div class="sectionbody">
<div class="paragraph"><p>This section is a compendium of a various useful tricks for debugging,

<div class="sect1">
<h2 id="_debugging_tricks">Debugging Tricks</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_examining_the_environment">Examining The Environment</h3>
<div class="sect3">
<h4 id="_during_config_file_processing">During Config File Processing</h4>
<div class="paragraph"><p>It is often helpful to know the content of variables in various
contexts as Megatest does the actions needed to run your tests. A handy technique is to force the startup of an xterm in the context being examined.</p></div>
<div class="paragraph"><p>For example, if an item list is not being generated as expected you
can inject the startup of an xterm as if it were an item:</p></div>
<div class="listingblock">
<div class="title">Original items table</div>
<div class="content monospaced">
<pre>[items]
CELLNAME [system getcellname.sh]</pre>
</div></div>
<div class="listingblock">
<div class="title">Items table modified for debug</div>
<div class="content monospaced">
<pre>[items]
DEBUG [system xterm]
CELLNAME [system getcellnames.sh]</pre>
</div></div>
<div class="paragraph"><p>When this test is run an xterm will pop up. In that xterm the
environment is exactly that in which the script "getcellnames.sh"
would run. You can now debug the script to find out why it isn&#8217;t
working as expected.</p></div>
</div>
<div class="sect3">
<h4 id="_organising_your_tests_and_tasks">Organising Your Tests and Tasks</h4>
<div class="paragraph"><p>The default location "tests" for storing tests can be extended by
adding to your tests-paths section.</p></div>
<div class="listingblock">
<div class="content monospaced">
<pre>[misc]
parent #{shell dirname $(readlink -f .)}

<pre>[tests-paths]
[tests-paths]
1 #{get misc parent}/simplerun/tests</pre>
</div></div>
<div class="paragraph"><p>The above example shows how you can use addition sections in your
config file to do complex processing. By putting results of relatively
slow operations into variables the processing of your configs can be
kept fast.</p></div>
</div>
<div class="sect3">
<h4 id="_alternative_method_for_running_your_job_script">Alternative Method for Running your Job Script</h4>
<div class="listingblock">
<div class="title">Directly running job in testconfig</div>
<div class="content monospaced">
<pre>[setup]</pre>
<pre>[setup]
runscript main.csh</pre>
</div></div>
<div class="paragraph"><p>The runscript method is a brute force way to run scripts where the
user is responsible for setting STATE and STATUS</p></div>
<div class="paragraph"><p>The runscript method is essentially a brute force way to run scripts where the
user is responsible for setting STATE and STATUS and managing the details of running a test.</p></div>
<div class="listingblock">
<div class="content monospaced">
<pre>runscript main.csh</pre>
</div></div>
</div>
</div>
<div class="sect2">
<h3 id="_debugging_server_problems">Debugging Server Problems</h3>
<div class="paragraph"><p>Some handy Unix commands to track down issues with servers not
communicating with your test manager processes. Please put in tickets
at <a href="https://www.kiatoa.com/fossils/megatest">https://www.kiatoa.com/fossils/megatest</a> if you have problems with
servers getting stuck.</p></div>
<div class="listingblock">
<div class="content monospaced">
<pre>sudo lsof -i
sudo netstat -lptu
sudo netstat -tulpn</pre>
</div></div>
</div>

</div>
<div class="sect3">
<h4 id="_mode">Mode</h4>
<div class="paragraph"><p>The default (i.e. if mode is not specified) is normal. All pre-dependent tests
must be COMPLETED and PASS, CHECK or WAIVED before the test will start</p></div>
<div class="listingblock">
<div class="content monospaced">
<pre>[requirements]
<pre>mode   normal</pre>
mode   normal</pre>
</div></div>
<div class="paragraph"><p>The toplevel mode requires only that the prior tests are COMPLETED.</p></div>
<div class="listingblock">
<div class="content monospaced">
<pre>[requirements]
<pre>mode toplevel</pre>
mode toplevel</pre>
</div></div>
<div class="paragraph"><p>A item based waiton will start items in a test when the
same-named item is COMPLETED and PASS, CHECK or WAIVED
in the prior test</p></div>
<div class="paragraph"><p>A item based waiton will start items in a test when the same-named
item is COMPLETED and PASS, CHECK or WAIVED in the prior test. This
was historically called "itemwait" mode. The terms "itemwait" and
"itemmatch" are synonyms.</p></div>
<div class="listingblock">
<div class="content monospaced">
<pre>[requirements]
<pre>mode itemmatch</pre>
mode itemmatch</pre>
</div></div>
</div>
<div class="sect3">
<h4 id="_itemmap">Itemmap</h4>
<div class="paragraph"><p>For cases were the dependent test has a similar but not identical
itempath to the downstream test an itemmap can allow for itemmatch
mode</p></div>
<div class="listingblock">
<div class="content monospaced">
<pre>[requirements]
mode itemmatch
itemmap .*x/ y/

# ## pattern replacement notes
#
# ## Example
# ## Remove everything up to the last /
itemmap .*/
#
# ## Example
# ## Replace foo/ with bar/
itemmap foo/ bar/</pre>
</div></div>
<div class="listingblock">
<div class="title">Autogeneration waiton list for dynamic flow dependency trees</div>
<div class="content monospaced">
<pre>[requirements]
<pre># With a toplevel test you may wish to generate your list
# With a toplevel test you may wish to generate your list
# of tests to run dynamically
#
# waiton #{shell get-valid-tests-to-run.sh}</pre>
</div></div>
</div>
<div class="sect3">
<h4 id="_run_time_limit">Run time limit</h4>
<div class="listingblock">
<div class="content monospaced">
<pre>runtimelim 1h 2m 3s  # this will automatically kill the test if it runs for more than 1h 2m and 3s</pre>
</div></div>
</div>
<div class="sect3">
<h4 id="_skip">Skip</h4>
</div>
<div class="sect3">
<div class="paragraph"><p>A test with a skip section will conditional skip running.</p></div>
<h4 id="_header_3">Header</h4>
<div class="listingblock">
<div class="title">Skip section example</div>
<div class="content monospaced">
<pre>[skip]</pre>
<pre>[skip]
prevrunning x
# rundelay 30m 15s</pre>
</div></div>
</div>
<div class="sect3">
<h4 id="_skip_on_still_running_tests">Skip on Still-running Tests</h4>
<div class="listingblock">
<div class="content monospaced">
<pre># NB// If the prevrunning line exists with *any* value the test will
# automatically SKIP if the same-named test is currently RUNNING
# automatically SKIP if the same-named test is currently RUNNING. The
# "x" can be any string. Comment out the prevrunning line to turn off
# skip.

[skip]
prevrunning x</pre>
</div></div>
</div>
<div class="sect3">
<h4 id="_skip_if_a_file_exists">Skip if a File Exists</h4>
<div class="listingblock">
<div class="content monospaced">
<pre>[skip]
<pre>fileexists /path/to/a/file # skip if /path/to/a/file exists</pre>
fileexists /path/to/a/file # skip if /path/to/a/file exists</pre>
</div></div>
</div>
<div class="sect3">
<h4 id="_skip_if_test_ran_more_recently_than_specified_time">Skip if test ran more recently than specified time</h4>
<div class="listingblock">
<div class="title">Skip if this test has been run in the past fifteen minutes and 15 seconds.</div>
<div class="content monospaced">
<pre>[skip]
rundelay 15m 15s</pre>
</div></div>
</div>
<div class="sect3">
<h4 id="_controlled_waiver_propagation">Controlled waiver propagation</h4>
<div class="paragraph"><p>If test is FAIL and previous test in run with same MT_TARGET is WAIVED then apply the following rules from the testconfig:
If a waiver check is specified in the testconfig apply the check and if it passes then set this FAIL to WAIVED</p></div>
<div class="paragraph"><p>Waiver check has two parts, 1) a list of waiver, rulename, filepatterns and 2) the rulename script spec (note that "diff" and "logpro" are predefined)</p></div>

<div class="content monospaced">
<pre>[triggers]
COMPLETED/ xterm -e bash -s --</pre>
</div></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<img src="/nfs/pdx/disks/ice.disk.001/icfadm/pkgs/asciidoc/8.6.7/images/icons/note.png" alt="Note">
<img src="/usr/images/icons/note.png" alt="Note">
</td>
<td class="content">There is a trailing space after the --</td>
</tr></table>
</div>
</div>
<div class="sect2">
<h3 id="_override_the_toplevel_html_file">Override the Toplevel HTML File</h3>

<h2 id="_programming_api">Programming API</h2>
<div class="sectionbody">
<div class="paragraph"><p>These routines can be called from the megatest repl.</p></div>
<table class="tableblock frame-topbot grid-all"
style="
width:70%;
">
<caption class="title">Table 2. API Server Management Calls</caption>
<caption class="title">Table 1. API Server Management Calls</caption>
<col style="width:14%;">
<col style="width:28%;">
<col style="width:28%;">
<col style="width:28%;">
<thead>
<tr>
<th class="tableblock halign-center valign-top" >API Call                  </th>

</tr>
</tbody>
</table>
<table class="tableblock frame-topbot grid-all"
style="
width:70%;
">
<caption class="title">Table 3. API Keys Related Calls</caption>
<caption class="title">Table 2. API Keys Related Calls</caption>
<col style="width:14%;">
<col style="width:28%;">
<col style="width:28%;">
<col style="width:28%;">
<thead>
<tr>
<th class="tableblock halign-center valign-top" >API Call                        </th>

<div class="sectionbody">
<div class="paragraph"><p>One or more optional appendixes go here at section level zero.</p></div>
<div class="sect2">
<h3 id="_appendix_sub_section">Appendix Sub-section</h3>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<img src="/nfs/pdx/disks/ice.disk.001/icfadm/pkgs/asciidoc/8.6.7/images/icons/note.png" alt="Note">
<img src="/usr/images/icons/note.png" alt="Note">
</td>
<td class="content">Preface and appendix subsections start out of sequence at level
2 (level 1 is skipped).  This only applies to multi-part book
documents.</td>
</tr></table>
</div>
</div>

</div>
</div>
</div>
<div id="footnotes"><hr></div>
<div id="footer">
<div id="footer-text">
Version 1.0<br>
Last updated 2015-06-22 12:55:58 PDT
Last updated
 2015-06-02 21:29:49 MST
</div>
</div>
</body>
</html>

Mode
^^^^

The default (i.e. if mode is not specified) is normal. All pre-dependent tests
must be COMPLETED and PASS, CHECK or WAIVED before the test will start

-------------------
[requirements]
mode   normal
-------------------

The toplevel mode requires only that the prior tests are COMPLETED.

-------------------
[requirements]
mode toplevel
-------------------

A item based waiton will start items in a test when the
same-named item is COMPLETED and PASS, CHECK or WAIVED
in the prior test
A item based waiton will start items in a test when the same-named
item is COMPLETED and PASS, CHECK or WAIVED in the prior test. This
was historically called "itemwait" mode. The terms "itemwait" and
"itemmatch" are synonyms.

-------------------
[requirements]
mode itemmatch
-------------------

Itemmap
^^^^^^^

For cases were the dependent test has a similar but not identical
itempath to the downstream test an itemmap can allow for itemmatch
mode

-------------------
[requirements]
mode itemmatch
itemmap .*x/ y/

# ## pattern replacement notes
#
# ## Example
# ## Remove everything up to the last /
itemmap .*/
#
# ## Example
# ## Replace foo/ with bar/
itemmap foo/ bar/
-------------------

.Autogeneration waiton list for dynamic flow dependency trees
-------------------
[requirements]
# With a toplevel test you may wish to generate your list 
# of tests to run dynamically
#
# waiton #{shell get-valid-tests-to-run.sh}
------------------
-------------------



Run time limit
^^^^^^^^^^^^^^

-----------------
runtimelim 1h 2m 3s  # this will automatically kill the test if it runs for more than 1h 2m and 3s
-----------------

Skip
^^^^

Header
A test with a skip section will conditional skip running.
^^^^^^

.Skip section example
-----------------
[skip]
prevrunning x
# rundelay 30m 15s
-----------------

Skip on Still-running Tests
^^^^^^^^^^^^^^^^^^^^^^^^^^^

-----------------
# NB// If the prevrunning line exists with *any* value the test will 
# automatically SKIP if the same-named test is currently RUNNING
# NB// If the prevrunning line exists with *any* value the test will
# automatically SKIP if the same-named test is currently RUNNING. The
# "x" can be any string. Comment out the prevrunning line to turn off
# skip.

[skip]
prevrunning x
-----------------

Skip if a File Exists
^^^^^^^^^^^^^^^^^^^^^

-----------------
[skip]
fileexists /path/to/a/file # skip if /path/to/a/file exists
-----------------

Skip if test ran more recently than specified time
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.Skip if this test has been run in the past fifteen minutes and 15 seconds.
-----------------
[skip]
rundelay 15m 15s
-----------------

Controlled waiver propagation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If test is FAIL and previous test in run with same MT_TARGET is WAIVED then apply the following rules from the testconfig:
If a waiver check is specified in the testconfig apply the check and if it passes then set this FAIL to WAIVED

Writing Tests
=============

The First Chapter of the Second Part
------------------------------------
Chapters grouped into book parts are at level 1 and can contain
sub-sections.
Creating a new Test
-------------------

The following steps will add a test "yourtestname" to your testsuite. This assumes
starting from a directory where you already have a megatest.config and
runconfigs.config.

. Create a directory tests/yourtestname
. Create a file tests/yourtestname/testconfig

.Contents of minimal testconfig
--------------------
[ezsteps]
stepname1 stepname.sh

# test_meta is a section for storing additional data on your test
[test_meta]
author myname
owner  myname
description An example test
reviewed never
--------------------

This test runs a single step called "stepname1" which runs a script
"stepname.sh". Note that although it is common to put the actions
needed for a test step into a script it is not necessary.

:numbered!:

Road Map
========

Note 1: This road-map is tentative and subject to change without notice.

Note 2: Starting over. Old plan is commented out.

Current Items
-------------

ww05 - migrate to inmem-db
~~~~~~~~~~~~~~~~~~~~~~~~~~

Keep as much the same as possible. Add internal reference to almost
eliminate contention on db(s). 

. Switch to inmem db with fast sync to on disk db's [DONE]
. Add internal reference db
. Verify that actions are accessing correct db
.. -runtests  - inmem
.. -list-runs - local (but not megatest.db)
.. dashboard  - local (but not megatest.db)
. Mirror db to /var/tmp...
. Dashboard read db from per-run db.
. Dashboard read db from /var/tmp
. Runs register in tasks table in monitor.db
. Server polls tasks table for next action (in addition?)
. Server polls tasks table for next action
. Change run loop to execute in server, triggered by call to polling of tasks table
.. Task table used for tracking runner process [DONE]
.. Task table used for jobs to run
.. Task table used for queueing runner actions (remove runs, cleanRunExecute, etc)


// ww32
// ~~~~
// 
// . Rerun step and or subsequent steps from gui
// . Refresh test area files from gui

;; Disabled help items
;;  -rollup                 : (currently disabled) fill run (set by :runname)  with latest test(s)
;;                            from prior runs with same keys

(define help (conc "
Megatest, documentation at http://www.kiatoa.com/fossils/megatest
  version " megatest-version "
  license GPL, Copyright Matt Welland 2006-2012
  license GPL, Copyright Matt Welland 2006-2015

Usage: megatest [options]
  -h                      : this help
  -version                : print megatest version (currently " megatest-version ")

Launching and managing runs
  -runall                 : run all tests or as specified by -testpatt

			"-show-config"
			"-show-cmdinfo"
			"-get-run-status"

			;; queries
			"-test-paths" ;; get path(s) to a test, ordered by youngest first

			"-runall"    ;; run all tests, respects -testpatt
			"-runall"    ;; run all tests, respects -testpatt, defaults to %
			"-run"       ;; alias for -runall
			"-remove-runs"
			"-rebuild-db"
			"-cleanup-db"
			"-rollup"
			"-update-meta"
			"-gen-megatest-area"

			"-logging"
			"-v" ;; verbose 2, more than normal (normal is 1)
			"-q" ;; quiet 0, errors/warnings only
		       )
		 args:arg-hash
		 0))

(if (and (not (null? remargs))
	 (not (or
	       (args:get-arg "-runstep"))
	      ;; add more args that use remargs here
	      ))
    (debug:print 0 "ERROR: Unrecognised arguments: " (string-intersperse remargs " ")))

;; The watchdog is to keep an eye on things like db sync etc.
;;
(define *time-zero* (current-seconds))
(define *watchdog*
  (make-thread 
   (lambda ()
     (thread-sleep! 0.05) ;; delay for startup

(if (or (args:get-arg "-runall")(args:get-arg "-run"))
    (general-run-call 
     "-runall"
     "run all tests"
     (lambda (target runname keys keyvals)
       (runs:run-tests target
		       runname
		       (args:get-arg "-testpatt")
		       (or (args:get-arg "-testpatt")
			   "%")
		       user
		       args:arg-hash))))

;;======================================================================
;; run one test
;;======================================================================

(define (runs:test-get-full-path test)
  (let* ((testname (db:test-get-testname   test))
	 (itempath (db:test-get-item-path test)))
    (conc testname (if (equal? itempath "") "" (conc "(" itempath ")")))))

;; This is the *new* methodology. One record to inform them and in the chaos, organise them.
;;
;; NOT YET UTILIZED
;;
(define (runs:create-run-record)
  (let* ((mconfig      (if *configdat*
		           *configdat*
		           (if (launch:setup-for-run)
		               *configdat*
		               (begin

	 (deferred          '()) ;; delay running these since they have a waiton clause
	 (runconfigf         (conc  *toppath* "/runconfigs.config"))
	 (test-records       (make-hash-table))
	 ;; need to process runconfigs before generating these lists
	 (all-tests-registry #f)  ;; (tests:get-all)) ;; (tests:get-valid-tests (make-hash-table) test-search-path)) ;; all valid tests to check waiton names
	 (all-test-names     #f)  ;; (hash-table-keys all-tests-registry))
	 (test-names         #f)  ;; (tests:filter-test-names all-test-names test-patts))
	 (required-tests     #f)  ;;(lset-intersection equal? (string-split test-patts ",") test-names))) ;; test-names)) ;; Added test-names as initial for required-tests but that failed to work
	 (required-tests     #f)  ;; Put fully qualified test/testpath names in this list to be done
	 (task-key           (conc (hash-table->alist flags) " " (get-host-name) " " (current-process-id)))
	 (tdbdat             (tasks:open-db)))

    (if (tasks:need-server run-id)(tasks:start-and-wait-for-server tdbdat run-id 10))

    (let ((sighand (lambda (signum)
		     ;; (signal-mask! signum) ;; to mask or not? seems to cause issues in exiting

    ;; Now generate all the tests lists
    (set! all-tests-registry (tests:get-all))
    (set! all-test-names     (hash-table-keys all-tests-registry))
    (set! test-names         (tests:filter-test-names all-test-names test-patts))

    ;; I think seeding required-tests with all test-names makes sense but lack analysis to back that up.

    ;; NEW STRATEGY HERE:
    ;; 1. fill required tests with test-patts
    ;; 2. scan testconfigs and if waitons, itemwait, itempatt calc prior test test-patt
    ;; 3. repeat until all deps propagated
    
    ;; any tests with direct mention in test-patts can be added to required
    ;;
    (set! required-tests     (lset-intersection equal? (string-split test-patts ",") all-test-names))
    ;; (set! required-tests     (lset-intersection equal? test-names all-test-names))
    
    ;; look up all tests matching the comma separated list of globs in
    ;; test-patts (using % as wildcard)

						(else #f)))                           ;; not iterated
					     #f      ;; itemsdat 5
					     #f      ;; spare - used for item-path
					     )))
	    (for-each 
	     (lambda (waiton)
	       (if (and waiton (not (member waiton test-names)))
		   (let ((new-test-patts (tests:extend-test-patts test-patts hed waiton #f)))
		     ;; need to account for test-patt here, if I am test "a", selected with a test-patt of "hed/b%"
		     ;; and we are waiting on "waiton" we need to add "waiton/,waiton/b%" to test-patt
		     ;; is this satisfied by merely appending "/" to the waiton name added to the list?
		     ;;
		     ;; This approach causes all of the items in an upstream test to be run 
		   (begin
		     (set! required-tests (cons waiton required-tests))

		     (debug:print-info 0 "new-test-patts: " new-test-patts ", prev test-patts: " test-patts)
		     (if (equal? new-test-patts test-patts)
			 (set! required-tests (cons waiton required-tests)) ;; (cons (conc waiton "/") required-tests))
			 (set! test-patts new-test-patts))
		     
		     ;; NOPE: didn't work. required needs to be plain test names. Try tacking on to test-patts
		     ;;  - doesn't work
		     ;; (set! test-patts (conc test-patts "," waiton "/"))
		     
		     (set! test-names (cons waiton test-names))))) ;; was an append, now a cons
	     waitons)
	    (let ((remtests (delete-duplicates (append waitons tal))))
	      (if (not (null? remtests))
		  (loop (car remtests)(cdr remtests)))))))

    (if (not (null? required-tests))
	(debug:print-info 1 "Adding " required-tests " to the run queue"))
	(debug:print-info 1 "Adding \"" (string-intersperse required-tests " ") "\" to the run queue"))
    ;; NOTE: these are all parent tests, items are not expanded yet.
    (debug:print-info 4 "test-records=" (hash-table->alist test-records))
    (let ((reglen (configf:lookup *configdat* "setup" "runqueue")))
      (if (> (length (hash-table-keys test-records)) 0)
	  (let* ((keep-going        #t)
		 (run-queue-retries 5)
		 (th1        (make-thread (lambda ()

	    ;; if run-count > 0 call, set -preclean and -rerun STUCK/DEAD
	    (if (> run-count 0)
		(begin
		  (if (not (hash-table-ref/default flags "-preclean" #f))
		      (hash-table-set! flags "-preclean" #t))
		  (if (not (hash-table-ref/default flags "-rerun" #f))
		      (hash-table-set! flags "-rerun" "STUCK/DEAD,n/a,ZERO_ITEMS"))
		  ;; recursive call to self
		  (runs:run-tests target runname test-patts user flags run-count: (- run-count 1)))))
	  (debug:print-info 0 "No tests to run")))
    (debug:print-info 4 "All done by here")
    (rmt:tasks-set-state-given-param-key task-key "done")
    ;; (sqlite3:finalize! tasks-db)
    ))

(define (tests:filter-test-names test-names test-patts)
  (delete-duplicates
   (filter (lambda (testname)
	     (tests:match test-patts testname #f))
	   test-names)))

;; given test-b that is waiting on test-a extend test-patt appropriately
;;
(define (tests:extend-test-patts test-patt test-b test-a itemmap)
  (let* ((patts      (string-split test-patt ","))
	 (test-b-len (+ (string-length test-b) 1))
	 (patts-b    (map (lambda (x)
			    (let ((newpatt (conc test-a "/" (substring x test-b-len (string-length x)))))
			      (print "in map, x=" x ", newpatt=" newpatt)
			      newpatt))
			  (filter (lambda (x)
				    (eq? (substring-index (conc test-b "/") x) 0))
				  patts))))
    (string-intersperse (delete-duplicates (append patts patts-b)) ",")))

;; tests:glob-like-match
(define (tests:glob-like-match patt str) 
  (let ((like (substring-index "%" patt)))
    (let* ((notpatt  (equal? (substring-index "~" patt) 0))
	   (newpatt  (if notpatt (substring patt 1) patt))
	   (finpatt  (if like
			(string-substitute (regexp "%") ".*" newpatt #f)

# Add additional steps here. Format is "stepname script"
[ezsteps]
step1 step1.sh

# Test requirements are specified here
[requirements]
waiton bigrun2
priority 0
mode itemwait
# pattern replacement
#
# Remove everything up to the last /
# itemmap .*/
#
# Replace foo/ with bar/
# itemmap foo/ bar/
# 
itemmap .*/

# Iteration for your tests are controlled by the items section
[items]
NUMBER #{scheme (string-intersperse (map (lambda (x)(conc "blah/" x)) \
                                         (map number->string (sort (let loop ((a 0)(res '())) \
                                                                        (if (<= a (or (any->number (get-environment-variable "NUMTESTS")) 2500)) \