| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Given the inheritance model for actions, we are sometimes going to need to set
them to 'default' at runtime, rather than during their static declaration.
Add tests to verify that this works correctly, and update the code to ensure
that happens. This gives up caching of the default action, but this should be
an extremely rare operation - pretty much only CLI invocation, really.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We earlier moved to duplicating Action objects in the Faces subsystem to
ensure they had the correct binding context during execution and introspection.
This was correct, but introduced a bug where we would report both the parent
and child binding as separate entries with duplicate names, in the list of
actions.
This flowed on to the help output, where it would cause every inherited action
to be listed twice: once on the parent, once on the child. (This was actually
worse if the inheritance was deeper: we would duplicate once for every level
between the instance and the origin of the action.)
|
| |
|
|
|
|
| |
Given that we have identical documentation behaviour in the face and action
code, it should properly be written once. So, move it into a module, extend
the other classes with it, and have done.
|
| |
|
|
|
|
|
| |
This also enables the 'help' action on the 'help'
face to serve as a default action.
Reviewed-By: Daniel Pittman
Reviewed-By: Nick Lewis
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We implemented the naive version of inheritance in the faces, in which an
action declared on a superclass remains bound to that even when accessed
from a subclass.
As a consequence our visibility of options on inherited classes is actually
much more limited than it should be, and the actions we inherit would never
see the options they should correctly have.
To fix this we correct the binding bug and handle lookup correctly over
inheritance in our code.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| |
|
|
|
|
|
|
|
| |
This splits out the plumbing into the Puppet::Interface namespace, and uses
Puppet::Faces for all the public-facing code.
The fault line is "what you care about if you are using or writing a face",
which is public, against "what you care about to enable either of those two",
which is the plumbing.
|
| |
|
|
|
|
|
| |
Now that we have settled on the final public name for the API,
"Puppet::String", mass-rename and mass-edit all the files to follow.
Reviewed-By: Randall Hansen <randall@puppetlabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment the action method is a fairly heavy tool: it provides a DSL, and
is designed to allow substantial metadata to be added to the action.
For some users this is low on value, since they just want to write a little
script that drives things a bit differently. Which there is substantial value
in the metadata, adding the capability to do these light-weight things quickly
is valid.
To meet this we add a script action; the contrast is:
action :foo do
# other metadata goes here
invoke do |args|
# method body goes here
end
end
script :bar do |args|
# method body goes here
end
# ...and if you want metadata, you have to add it in more ugly, procedural
# ways, which we are not going to encourage.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| |
|
|
| |
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This class will represents an action, and allows us to store metadata for an
action, and programmatically introspect and invoke them. A helper class
ActionBuilder represents the DSL for defining an action.
Also defined an "invoke" DSL method to handle the functionality of defining the
method for an action.
Reviewed-By: Daniel Pittman
|
|
|
They were previously classes, which made a lot of things stupider
than they needed to be.
This will likely involve some porting, but not much.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
