* Command
capabilities
response, for example
- ok efficient-diff revert ...
+ ok gnomovision-server revert ...
where the words after ok are features that not all regimes
support. Valid in all states.
Currently defined capabilities:
+ + revert
+ The "revert" command is supported. The base semantics
+ are that the following aspects of the testbed are reverted:
+ - the set of installed packages
+ - the contents of the root filesystem, BUT
+ - NOT the contents of /home
+ - NOT the contents of /tmp
+ - NOT the set of running processes
+
+ + revert-full-system
+ The "revert" and "close" commands will completely revert the
+ testbed to the state after "open". This reversion is done
+ with some kind of virtualisation, and includes (without
+ limitation) the contents of all the testbed filesystems, its
+ running processes, network configuration, etc. etc. etc.
+
+ revert
The testbed will actually revert when it is closed. If this
feature is not mentioned then changes to the testbed are
(with distinct <username>s) may be advertised in which case
more than one such user is available.
- + print-execute-command
- The 'print-execute-command' command is available, so that the
- caller can execute multiple concurrent commands on the testbed
- with asynchronous input and output, if desired.
-
* Command
open
Checks that the testbed is present and reserves it (waiting for
other uses of the testbed to finish first, if necessary). State:
Closed to Open. <testbed-scratchspace> is a pathname on the
- testbed which can be used freely by the test scripts.
+ testbed which can be used freely by the test scripts and which
+ is valid until the next `close', `revert' or `quit'.
* Command
revert
+ response
+ ok <testbed-scratchspace>
Restores the testbed, undoing all of the changes made so far.
State: Open, remains Open. Only available if the `revert'
advertised). State: Open to Closed.
-* Command
- print-execute-command
+* Commands
+ print-auxverb-command
+ print-shstring-command
response
- ok <program>,<arg>,<arg>... auxverb|shstring [<keyword-info> ...]
+ ok <program>,<arg>,<arg>... [<keyword-info> ...]
Prints a command that can be executed by the caller to run a command
- on the testbed. Only available if the `print-execute-command'
- capability is advertised.
+ on the testbed.
The command has the following properties (which are, for example,
satisfiable when the virt server uses `env' `ssh' or `dchroot'):
- The caller is expected to url-decode <program> and each <arg>,
append the command to be run on the testbed, and call exec on the
results.
- - If auxverb is advertised, the supplied additional arguments to
- command will be interpreted as the command and arguments to be
- run on the testbed (as env and nice interpret their arguments)
- - If shstring is advertised, there should be one additional
- argument which will be fed to sh -c on the testbed (this is the
- way ssh interprets its arguments).
+ - For the command provided by `print-auxverb-command', the supplied
+ additional arguments to command will be interpreted as the
+ command and arguments to be run on the testbed (as env and nice
+ interpret their arguments)
+ - The command provided by `print-shstring-command', should be
+ invoked with exactly one additional argument which should be a
+ legal shell script. It will be fed to sh -c on the testbed (this
+ is the way ssh interprets its arguments).
- The testbed program's stdin, stdout and stderr will be plumbed
through to the stdin, stdout and stderr passed to <program>; this
may involve fd passing, or indirection via pipes or sockets. The
response
ok <exit-status>
- Executes the command (args separated by commas, everything
- url-encoded). stdin, stdout, stderr are files on the testbed
- (must be files, not pipes).
+ Executes the command (args separated by commas, everything including
+ filenames and env var names and values url-encoded). stdin, stdout,
+ stderr are files on the testbed (must be files, not pipes).
Currently defined keyword arguments:
that facility is available.
* Commands
- copydown <host-tree> <testbed-path>
- copyup <testbed-tree> <host-path>
+ copydown <host-path> <testbed-path>
+ copyup <testbed-path> <host-path>
- Like cp -dR --preserve=mode,timestamps exce[t across the testbed
- boundary.
+ Either
+
+ 1. Both paths end in `/', in which case the source must be an
+ existing directory. The destination directory is replaced with a
+ copy as if made by cp -dR --preserve=mode,timestamps except
+ across the testbed boundary.
+
+ 2. Neither path ends in `/', in which case the source must be an
+ existing file. The data from the source file is written to the
+ destination as if via shell redirection; except that if for
+ copydown of an executable file, `chmod +x' is run on the
+ destination file after the copy.
+
+ Both filenames are url-encoded.
* Command
the testbed is unreserved and restored to its original state (ie,
closed), and the regime server will print a message to stderr (unless
it is dying with a signal).
-
-The representation of changes to the local filesystem is a directory
-containing zero or more of:
- + changed-files: list of filenames, each one nul-terminated
- + other formats with other data or combinations of data
- (for future use)
-
~ianmdlvl / autopkgtest.git / blobdiff