Represent a registry for remote environment variables, will follow an
API similar to Hash except the constructor. Currently only #has_key? is
implemented.
In Condition:
* Modify constructor to accepts tests and a default return value;
* Implement #met?;
* Modify #! so that it return the negated value returned by #met?.
In Condition::DSL:
* Modify .evaluate to build the condition with tests and the value
returned by a the evaluated condition block.
Add a basic Test base class, with env and arguments as attributes.
Add some spec helpers to build some easily testable kind of Test
instances (as test doubles).
Use instance_eval so that the assigned block is evaluated inside the
DSL sandbox instance, giving access to all required methods and instance
variables.
Add the necessary API so that we can implement new tests easily as new
standalone classes.
In Condition::DSL:
* Add #tests accessor;
* Modify constructor so that it accepts the env;
* Implement .define_test(keyword, class) method.
Instead of interrupting task evaluation when condition is not met,
allow the whole task to be evaluated (including condition and
evaluation) so that the interpreter will get all tasks actions (whether
condition is met or not) and be able to query the condition.
* Modify Interpreter#process_task: test if task condition is met before
applying the actions;
* Implement condition handling in Task and Task::DSL;
* Implement Condition and Condition::DSL (useless as they are, but
needed to implement later test keywords as part of the condition DSL.
Remove most of task evaluation code from Task class, rely on
Task::DSL.evaluate to get an evaluated task.
* Task: remove #evaluate, change constructor prototype to accept actions
instead of a block, implement .evaluate(name, env &block);
* Implement Task::DSL.evaluate method;
* Recipe::DSL: remove tasks evaluation from#evaluate, modify #task to
use Task.evaluate to return the new task to be rigstered.
Remove most of recipe evaluation code in Recipe class, and rely on
Recipe::DSL to get evaluated recipes.
* Remove Recipe#evaluate call from CLI, rely on
Recipe.evaluate_from_file to get the evaluated recipe;
* Implement Recipe.evaluate_from_file(filepath, env);
* Implement Recipe::DSL.evaluate(code, env);
* Remove code and filepath accessor on Recipe;
* Remove Recipe.from_file and Recipe#evaluate methods;
* Move task evaluations in Recipe::DSL#evaluate;
* Modify Recipe constructor so that it accepts tasks as argument.
* Move recipe processing code in the worker;
* Refactor CLI and use the the worker;
* Implement Recipe#tasks and remove tasks application during evaluation,
tasks are now applied by the worker after all evaluations are done.
Fork an sshd server available for the duration of the scenario.
$HOME will be set to aruba temporary directory, and a custom ssh
config will be written so that the test server is accessible with the
alias `some_host.test'. sshd will listen on port 2222 by default, this
can be overridden by setting DEFAULT_LISTEN_PORT environment variable to
the desired port.
* Throw symbols instead of raising exceptions to test code evaluation,
this will reduce "bad" usages of exceptions, symbols seems a little
better for now;
* Add a specific exception to be used in specs for testing behaviour
when an exception is raised from a recipe.
* Report invalid action usages from tasks;
* Implement backtrace cleaning in CLI;
* Extract error class declarations in a new errors file;
* Replace raise with fail keyword in task DSL class.
Currently the idea is to later implement a -h (or -t) option to the
command, and/or a `target' recipe keyword. Another option might be to
use the target/host key when the key/value registry will be implemented
and made available to the recipe and task DSLs.
Thibault Jouan