Creating a testsuite or flow and your first test or task.
Megatest Internals
+
+
+
+
+
+
+The Megatest project was started for two reasons, the first was an immediate and pressing need for a generalized tool to manage a suite -of regression tests and the second was the fact that the author had -written or maintained several such tools at different companies over -the years and it seemed a good thing to have a single open source -tool, flexible enough to meet the needs of any team doing continuous -integrating and or running a complex suite of tests for release -qualification.
-- Matt Welland, original author of the Megatest tool suite.+
Self-checking -Repeatable strive for directed or self-checking test - as opposed to delta based tests + as opposed to delta based tests.
Traceable - environment variables, host OS and other possibly influential @@ -843,22 +847,22 @@ variables are captured and kept recorded.
-Immutable - once this test is run it cannot be easily overwritten or - accidentally modified. +Immutable - once a test is run it cannot be easily overwritten or + modified accidentally.
-Repeatable - this test result can be recreated in the future +Repeatable - test results can be recreated in the future using all the original variables.
-Relocatable - the testsuite or automation area can be checked out and the tests run anywhere +Relocatable - the testsuite or automation area can be checked out and the tests run anywhere in the disk hierarchy.
Encapsulated - the tests run in self-contained directories and all inputs @@ -865,26 +869,67 @@ and outputs to the process can be found in the run areas.
-Deployable - anyone on the team, at any site, at any time can run the flow +Deployable - a testsuite is self-contained and can be bundled with a software project.
All data to specify the tests and configure the system is stored in -plain text files. All system state is stored in an sqlite3 -database. Tests are launched using the launching system available for -the distributed compute platform in use. A template script is provided +plain text config files. All system state is stored in an sqlite3 +database.
Tests are launched using the launching system available for the +distributed compute platform in use. A template script is provided which can launch jobs on local and remote Linux hosts. Currently megatest uses the network filesystem to call home to your master -sqlite3 database.
Chicken scheme and a number of "eggs" are required for building +Megatest. See the script installall.sh in the utils directory of the +source distribution for an automated way to install everything +needed for building Megatest on Linux.
Creating a testsuite or flow and your first test or task.
+Chicken scheme and a number of "eggs" are required for building -Megatest. See the script installall.sh in the utils directory of the -source distribution for an automated way to install everything -needed for building Megatest on Linux.
Creating a testsuite or flow and your first test or task.
After installing Megatest you can create a flow or testsuite and add some -tests using the helpers. Here is a quickstart sequence to get you up and -running your first automated testsuite.
First choose your "target" keys. These are used to organise your runs in a -way that is meaningful to your project. If you are unsure about what to use -for keys just use a single generic key such as "RUNTYPE". These keys will be -used to hand values to your tests via environment variables so ensure they -are unique. Prefixing them with something such as PROJKEYS_ is a good -strategy.
Examples of keys:
| Option | -Description | -
|---|---|
RELEASE/ITERATION |
-This example is used by Megatest for its internal QA. |
-
ARCH/OS/RELEASE |
-For a software project targeting multiple platforms |
-
UCTRLR/NODETYPE |
-Microcontroller project with different controllers -running same software |
-
You will need to choose locations for your runs (the data generated every -time you run the testsuite) and link tree. For getting started answer the -prompts with "runs" and "links". We use the Unix editor "vi" in the examples -below but you can use any plain text editor.
megatest -create-megatest-area - -# optional: verify that the settings are ok -vi megatest.config -vi runconfigs.config-
Choose the test name for your first test and run the helper. You can edit -the files after the initial creation. You will need to enter names and -scripts for the steps to be run and then edit the -tests/<testname>/testconfig file and modify the logpro rules to properly -process the log output from your steps. For your first test just hit enter -for the "waiton", "priority" and iteration variable prompts.
Hint: for geting started make your logpro rules very liberal. expect:error -patterns should match nothing and comment out expect:required rules.
megatest -create-test myfirsttest - -# then edit the generated config -vi tests/myfirsttest/testconfig-
First choose a target and runname. If you have a two-place target such as -RELEASE/ITERATION a target would look like v1.0/aff3 where v1.0 is the -RELEASE and aff3 is the ITERATION. For a run name just use something like -run1.
megatest -run -target v1.0/aff3 -runname run1 -testpatt % -log run1.log-
Start the dashboard and browse your run in the "Runs" tab.
dashboard -rows 24-
Megatest is an extensive program with a lot to learn. Following are some paths through the material to smooth the learning path.
-Components of automation; run, test, iteration -
--Selectors; target, runname, and testpatt -
--Using the dashboard gui (recommended) -
--Using the "Runs" panel. -
--Using the "Run Control" panel. -
--Using a test control panel -
--The Right Mouse Button menu -
--Debug features -
--xterm -
--pstree -
--log files; mt_copy.log, mt_launch.log -
--variables; megatest.csh, megatest.sh -
--testconfig dump, *testconfig -
--State/status buttons -
--Run, Clean, KillReq -
--ReRunClean -
--Using the command line -
--Getting help; megatest -h, megatest -manual -
--Starting runs; megatest -run -
--Selection controls; -target, -runname and -testpatt -
--tests/testname/testconfig testconfig details -
--iteration (one test applied to many inputs) test iteration -
--dependencies test requirements -
--megatest areas -
--megatest.config -
--Removing and keeping runs selectively managing runs -
--Subruns nested runs -
--Config file features config file features -
-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 -
-[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.
From the dashboard click on the button (PASS/FAIL…) for one of the tests. From the test control panel that -comes up push the clean test button. The command field will be prefilled with a template command for removing -that test. You can edit the command, for example change the argument to -testpatt to "%" to remove all tests.
megatest -remove-runs -target ubuntu/nfs/none -runname ww28.1a -testpatt diskperf/% -v-
megatest -remove-runs -target %/%/% -runname % -testpatt % -v-
Megatest supports using the bup backup tool (https://bup.github.io/) to archive your tests for efficient storage -and retrieval. Archived data can be rapidly retrieved if needed. The metadata for the run (PASS/FAIL status, run -durations, time stamps etc.) are all preserved in the megatest database.
For setup information see the Archiving topic in the reference section of this manual.
Hint: use the test control panel to create a template command by pushing the "Archive Tests" button.
megatest -target ubuntu/nfs/none -runname ww28.1a -archive save-remove -testpatt %-
megatest -target ubuntu/nfs/none -runname ww28.1a -archive restore -testpatt diskperf/%-
Hint: You can browse the archive using bup commands directly.
bup -d /path/to/bup/archive ftp-
[host-types]
-general ssh #{getbgesthost general}
-nbgeneral nbjob run JOBCOMMAND -log $MT_LINKTREE/$MT_TARGET/$MT_RUNNAME.$MT_TESTNAME-$MT_ITEM_PATH.lgo
-
-[hosts]
-general cubian xena
-
-[launchers]
-envsetup general
-xor/%/n 4C16G
-% nbgeneral
-
-[jobtools]
-launcher bsub
-# if defined and not "no" flexi-launcher will bypass launcher unless there is no
-# match.
-flexi-launcher yes
-This section is a compendium of a various useful tricks for debugging, -configuring and generally getting the most out of Megatest.
The following example will limit a test in the jobgroup "group1" to no more than 10 tests simultaneously.
In your testconfig:
[test_meta] -jobgroup group1-
In your megatest.config:
[jobgroups] -group1 10 -custdes 4-
From the dashboard click on a test PASS/FAIL button. This brings up a test control panel. Aproximately near the center left of the -window there is a button "Start Xterm". Push this to get an xterm with the full context and environment loaded for that test. You can run -scripts or ezsteps by copying from the testconfig (hint, load up the testconfig in a separate gvim or emacs window). This is the easiest way -to debug your tests.
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:
[items] -CELLNAME [system getcellname.sh]-
[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.
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
-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.
[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.
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-
| Use case | -Megatest command | -mtutil | -
|---|---|---|
Start from scratch |
--rerun-all |
-restart |
-
Rerun non-good completed |
--rerun-clean |
-rerunclean |
-
Rerun all non-good and not completed yet |
--set-state-status KILLREQ; -rerun- |
-clean |
-
killrerun |
-Continue run |
--run |
-
resume |
-Remove run |
--remove-runs |
-
clean |
-Lock run |
--lock |
-
lock |
-Unlock run |
--unlock |
-
unlock |
-killrun |
--set-state-status KILLREQ; -kill-run |
-
Various helpers for more advanced config files.
| Helper | -Purpose | -Valid values | -Comments | -
|---|---|---|---|
#{scheme (scheme code…)} |
-Execute arbitrary scheme code |
-Any valid scheme |
-Value returned from the call is converted to a string and processed as part of the config file |
-
#{system command} |
-Execute program, inserts exit code |
-Any valid Unix command |
-Discards the output from the program |
-
#{shell command} or #{sh …} |
-Execute program, inserts result from stdout |
-Any valid Unix command |
-Value returned from the call is converted to a string and processed as part of the config file |
-
#{realpath path} or #{rp …} |
-Replace with normalized path |
-Must be a valid path |
-- |
#{getenv VAR} or #{gv VAR} |
-Replace with content of env variable |
-Must be a valid var |
-- |
#{get s v} or #{g s v} |
-Replace with variable v from section s |
-Variable must be defined before use |
-- |
#{rget v} |
-Replace with variable v from target or default of runconfigs file |
-- | - |
| - | Replace with the path to the megatest testsuite area |
-- | - |
Settings in megatest.config
Including output from a script as if it was inline to the config file:
[scriptinc myscript.sh]-
If the script outputs:
[items] -A a b c -B d e f-
Then the config file would effectively appear to contain an items section -exactly like the output from the script. This is useful when dynamically -creating items, itemstables and other config structures. You can see the -expansion of the call by looking in the cached files (look in your linktree -for megatest.config and runconfigs.config cache files and in your test run -areas for the expanded and cached testconfig).
Wildcards and regexes in Targets
[a/2/b] -VAR1 VAL1 - -[a/%/b] -VAR1 VAL2-
Will result in:
[a/2/b] -VAR1 VAL2-
Can use either wildcard of "%" or a regular expression:
[/abc.*def/]-
Some parameters you can put in the [setup] section of megatest.config:
# minimum space required in a run disk -minspace 10000000 - -# minimum space required in dbdir: -dbdir-space-required 100000 - -# script that takes path as parameter and returns number of bytes available: -free-space-script check-space.sh-
[configf:settings trim-trailing-spaces yes]-
[host-types] -general nbfake -remote bsub - -[launchers] -runfirst/sum% remote -% general - -[jobtools] -launcher bsub -# if defined and not "no" flexi-launcher will bypass launcher unless -# there is no host-type match. -flexi-launcher yes-
List of host types and the commandline to run a job on that host type.
general nbfake-
runfirst/sum% remote-
Attempt to rerun tests in "STUCK/DEAD", "n/a", "ZERO_ITEMS" states.
[setup] -reruns 5-
Replace the default blacklisted environment variables with user supplied -list.
Default list: USER HOME DISPLAY LS_COLORS XKEYSYMDB EDITOR MAKEFLAGS MAKEF MAKEOVERRIDES
in the megatest.sh and megatest.csh files:
[setup] -blacklistvars USER HOME DISPLAY LS_COLORS XKEYSYMDB EDITOR MAKEFLAGS PROMPT-
[setup] -# this will automatically kill the test if it runs for more than 1h 2m and 3s -runtimelim 1h 2m 3s-
The tests browser (see the Run Control tab on the dashboard) has two views for displaying the tests.
-Dot (graphviz) based tree -
--No dot, plain listing -
-The default is the graphviz based tree but if your tests don’t view -well in that mode then use "nodot" to turn it off.
[setup] -nodot-
In a test you can capture arbitrary variables and roll them up in the -megatest database for viewing on the dashboard or web app.
$MT_MEGATEST -load-test-data << EOF -foo,bar, 1.2, 1.9, > -foo,rab, 1.0e9, 10e9, 1e9 -foo,bla, 1.2, 1.9, < -foo,bal, 1.2, 1.2, < , ,Check for overload -foo,alb, 1.2, 1.2, <= , Amps,This is the high power circuit test -foo,abl, 1.2, 1.3, 0.1 -foo,bra, 1.2, pass, silly stuff -faz,bar, 10, 8mA, , ,"this is a comment" -EOF-
Alternatively you can use logpro triggers to capture values and inject them -into megatest using the -set-values mechanism:
Test data capture - -set-values : update or set values in the testdata table - :category : set the category field (optional) - :variable : set the variable name (optional) - :value : value measured (required) - :expected : value expected (required) - :tol : |value-expect| <= tol (required, can be <, >, >=, <= or number) - :units : name of the units for value, expected_value etc. (optional)-
[dashboard] -btn-height x14 -btn-fontsz 10 -cell-width 60-
| Var | -Purpose | -Valid values | -Comments | -
|---|---|---|---|
delay-on-busy |
-Prevent concurrent access issues |
-yes|no or not defined |
-Default=no, may help on some network file systems, may slow things down also. |
-
faststart |
-All direct file access to sqlite db files |
-yes|no or not defined |
-Default=yes, suggest no for central automated systems and yes for interactive use |
-
homehost |
-Start servers on this host |
-<hostname> |
-Defaults to local host |
-
hostname |
-Hostname to bind to |
-<hostname>|- |
-On multi-homed hosts allows binding to specific hostname |
-
lowport |
-Start searching for a port at this portnum |
-32768 |
-- |
required |
-Server required |
-yes|no or not defined |
-Default=no, force start of server always |
-
server-query-threshold |
-Start server when queries take longer than this |
-number in milliseconds |
-Default=300 |
-
timeout |
-http api timeout |
-number in hours |
-Default is 1 minute, do not change |
-
[setup]-
The runscript method is a brute force way to run scripts where the -user is responsible for setting STATE and STATUS
runscript main.csh-
# full combinations -[items] -A x y -B 1 2 - -# Yields: x/1 x/2 y/1 y/2 - -# tabled -[itemstable] -A x y -B 1 2 - -# Yields x/1 y/2-
[requirements]-
# A normal waiton waits for the prior tests to be COMPLETED -# and PASS, CHECK or WAIVED -waiton test1 test2-
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. This -was historically called "itemwait" mode. The terms "itemwait" and -"itemmatch" are synonyms.
[requirements] -mode itemmatch-
Override variables before starting the test. Can include files (perhaps generated by megatest -envdelta or similar).
[pre-launch-env-vars]
-VAR1 value1
-
-# Get some generated settings
-[include ../generated-vars.config]
-
-# Use this trick to unset variables
-#{scheme (unsetenv "FOOBAR")}
-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 itemwait -# itemmap <item pattern for this test> <item replacement pattern for waiton test> -itemmap .*x/ y/-
# ## pattern replacement notes -# -# ## Example -# ## Remove everything up to the last / -[requirements] -mode itemwait -# itemmap <item pattern for this test> <nothing here indicates removal> -itemmap .*/-
# -# ## Example -# ## Replace foo/ with bar/ -[requirements] -mode itemwait -# itemmap <item pattern for this test> <item replacement pattern for waiton test> -itemmap foo/ bar/-
#
-# ## Example
-# ## can use \{number} in replacement pattern to backreference a (capture) from matching pattern similar to sed or perl
-[requirements]
-mode itemwait
-# itemmap <item pattern for this test> <item replacement pattern for waiton test>
-itemmap foo(\d+)/ num-\1/bar/
-# multi-line; matches are applied in the listed order -# The following would map: -# a123b321 to b321fooa123 then to 321fooa123p -# -[requirements] -itemmap (a\d+)(b\d+) \2foo\1 - b(.*) \1p-
Complex mappings can be handled with a separate [itemmap] section (instead if an itemmap line in the [requirements] section)
Each line in an itemmap section starts with a waiton test name followed by an itemmap expression
[itemmap] -A foo/ bar/ -B stuff/-
-We accomplish this by configuring the testconfigs of our tests C D and E as follows:
[requirements] -waiton C -itemmap (\d+)/res \1/bb-
[requirements] -waiton C -itemmap (\d+)/res \1/aa-
[requirements] -waiton A B - -[itemmap] -A (\d+)/aa aa/\1 -B (\d+)/bb bb/\1-
-eg from command line megatest -run -testpatt D/1/res -target mytarget -runname myrunname -
--Full list to be run is now: D/1/res -
--Test D has a waiton - test C. Test D’s itemmap rule itemmap (\d+)/res \1/aa → causes C/1/aa to run before D/1/res -
--Full list to be run is now: D/1/res, C/1/aa -
--Test C was a waiton - test A. Test C’s rule A (\d+)/aa aa/\1 → causes A/aa/1 to run before C/1/aa -
--Full list to be run is now: D/1/res, C/1/aa, A/aa/1 -
--Test A has no waitons. All waitons of all tests in full list have been processed. Full list is finalized. -
-An alternative to defining items is the itemstable section. This lets you define the itempath in a table format rather than specifying components and relying on getting all permutations of those components.
[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}
-[requirements] -runtimelim 1h 2m 3s # this will automatically kill the test if it runs for more than 1h 2m and 3s-
A test with a skip section will conditional skip running.
[skip] -prevrunning x -# rundelay 30m 15s-
# 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] -fileexists /path/to/a/file # skip if /path/to/a/file exists-
[skip] -rundelay 15m 15s-
A disks section in testconfig will override the disks section in -megatest.config. This can be used to allocate disks on a per-test or per item -basis.
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
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)
###### EXAMPLE FROM testconfig ######### -# matching file(s) will be diff'd with previous run and logpro applied -# if PASS or WARN result from logpro then WAIVER state is set -# -[waivers] -# logpro_file rulename input_glob -waiver_1 logpro lookittmp.log - -[waiver_rules] - -# This builtin rule is the default if there is no <waivername>.logpro file -# diff diff %file1% %file2% - -# This builtin rule is applied if a <waivername>.logpro file exists -# logpro diff %file1% %file2% | logpro %waivername%.logpro %waivername%.html-
[ezsteps] -lookittmp ls /tmp - -[logpro] -lookittmp ;; Note: config file format supports multi-line entries where leading whitespace is removed from each line - ;; a blank line indicates the end of the block of text - (expect:required in "LogFileBody" > 0 "A file name that should never exist!" #/This is a awfully stupid file name that should never be found in the temp dir/)-
To transfer the environment to the next step you can do the following:
$MT_MEGATEST -env2file .ezsteps/${stepname}
-In your testconfig or megatest.config triggers can be specified
[triggers] - -# Call script running.sh when test goes to state=RUNNING, status=PASS -RUNNING/PASS running.sh - -# Call script running.sh any time state goes to RUNNING -RUNNING/ running.sh - -# Call script onpass.sh any time status goes to PASS -PASS/ onpass.sh-
Scripts called will have; test-id test-rundir trigger test-name item-path state status event-time, added to the commandline.
HINT
To start an xterm (useful for debugging), use a command line like the following:
[triggers] -COMPLETED/ xterm -e bash -s ---
-
- |
-There is a trailing space after the -- | -
There are a number of environment variables available to the trigger script -but since triggers can be called in various contexts not all variables are -available at all times. The trigger script should check for the variable and -fail gracefully if it doesn’t exist.
| Variable | -Purpose | -
|---|---|
MT_TEST_RUN_DIR |
-The directory where Megatest ran this test |
-
MT_CMDINFO |
-Encoded command data for the test |
-
MT_DEBUG_MODE |
-Used to pass the debug mode to nested calls to Megatest |
-
MT_RUN_AREA_HOME |
-Megatest home area |
-
MT_TESTSUITENAME |
-The name of this testsuite or area |
-
MT_TEST_NAME |
-The name of this test |
-
MT_ITEM_INFO |
-The variable and values for the test item |
-
MT_MEGATEST |
-Which Megatest binary is being used by this area |
-
MT_TARGET |
-The target variable values, separated by / |
-
MT_LINKTREE |
-The base of the link tree where all run tests can be found |
-
MT_ITEMPATH |
-The values of the item path variables, separated by / |
-
MT_RUNNAME |
-The name of the run |
-
Megatest generates a simple html file summary for top level tests of -iterated tests. The generation can be overridden. NOTE: the output of -the script is captured from stdout to create the html.
# Override the rollup for specific tests -[testrollup] -runfirst mysummary.sh-
In megatest.config add the following sections:
[archive] -# where to get bup executable -# bup /path/to/bup - -[archive-disks] - -# Archives will be organised under these paths like this: -# <testsuite>/<creationdate> -# Within the archive the data is structured like this: -# <target>/<runname>/<test>/ -archive0 /mfs/myarchive-data/adisk1-
It is often necessary to capture and or manipulate environment -variables. Megatest has some facilities built in to help.
# capture the current enviroment into a db called envdat.db under -# the context "before" -megatest -envcap before - -# capture the current environment into a db called startup.db with -# context "after" -megatest -envcap after startup.db - -# write the diff from before to after -megatest -envdelta before-after -dumpmode bash-
Dump modes include bash, csh and config. You can include config data -into megatest.config or runconfigs.config.
megatest -envcap original -# do some stuff here -megatest -envcap munged -megatest -envdelta original-munged -dumpmode ini -o modified.config-
Then in runconfigs.config
cat testconfig -[pre-launch-env-vars] -[include modified.config]-
It is often desired to keep some older runs around but this must be balanced with the costs of disk space.
-Use -remove-keep -
--Use -archive (can also be done from the -remove-keep interface) -
--use -remove-runs with -keep-records -
-# use -precmd 'sleep 5;nbfake' to limit overloading the host computer but to allow the removes to run in parallel. -megatest -actions print,remove-runs -remove-keep 3 -target %/%/%/% -runname % -age 1w -precmd 'sleep 5;nbfake'"-
A Megatest test can run a full Megatest run in either the same -Megatest area or in another area. This is a powerful way of chaining -complex suites of tests and or actions.
If you are not using the current area you can use ezsteps to retrieve -and setup the sub-Megatest run area.
In the testconfig:
[subrun]
-
-# Required: wait for the run or just launch it
-# if no then the run will be an automatic PASS irrespective of the actual result
-run-wait yes|no
-
-# Optional: where to execute the run. Default is the current runarea
-run-area /some/path/to/megatest/area
-
-# Optional: method to use to determine pass/fail status of the run
-# auto (default) - roll up the net state/status of the sub-run
-# logpro - use the provided logpro rules, happens automatically if there is a logpro section
-# passfail auto|logpro
-# Example of logpro:
-passfail logpro
-
-# Optional:
-logpro ;; if this section exists then logpro is used to determine pass/fail
- (expect:required in "LogFileBody" >= 1 "At least one pass" #/PASS/)
- (expect:error in "LogFileBody" = 0 "No FAILs allowed" #/FAIL/)
-
-# Optional: target translator, default is to use the parent target
-target #{shell somescript.sh}
-
-# Optional: runname translator/generator, default is to use the parent runname
-run-name #{somescript.sh}
-
-# Optional: testpatt spec, default is to first look for TESTPATT spec from runconfigs unless there is a contour spec
-test-patt %/item1,test2
-
-# Optional: contour spec, use the named contour from the megatest.config contour spec
-contour contourname ### NOTE: Not implemented yet! Let us know if you need this feature.
-
-# Optional: mode-patt, use this spec for testpatt from runconfigs
-mode-patt TESTPATT
-
-# Optional: tag-expr, use this tag-expr to select tests
-tag-expr quick
-
-# Optional: (not yet implemented, remove-runs is always propagated at this time), propagate these actions from the parent
-# test
-# Note// default is % for all
-propagate remove-runs archive ...
-These routines can be called from the megatest repl.
| API Call | -Purpose comments | -Returns | -Comments | -
|---|---|---|---|
(rmt:get-key-val-pairs run-id) |
-- | #t=success/#f=fail |
-Works only if the server is still reachable |
-
(rmt:get-keys run-id) |
-- | ( key1 key2 … ) |
-- |
-