| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We previously used *args to collect all arguments to the action when_invoked
block, then tried vaguely to massage some little bits of them into the right
shape.
Methods defined with blocks, in Ruby 1.8, also have some fun behaviours. The
most special is that if you pass more than one argument to a block defined
with only one Ruby will automatically coerce the arguments into an array – and
this is preserved when it is bound to a method.
This led to routine situations where we would pass the wrong number of
arguments to the block because, say, the user gave an extra argument on the
command line.
Instead of failing this would transmogrify the arguments in counterintuitive
ways, and end up with horrible stack traces when that interacted badly with
the code as written.
Now, instead, we work out the right argument format based on the arguments
that the when_invoked block takes. This gives much better (albeit perhaps not
so user friendly) behaviour at the interface level. Which is, at least,
consistent with other Ruby API.
Reviewed-By: Max Martin <max@puppetlabs.com>
|
|
Fix the conflicts over changes in my previous commit.
|
|
We no longer establish the rendering mode in the actions; they just default to
"nothing", and let that flow on out to the application layer. That lets the
facade we put before the face determine the default behaviour.
This is mostly a no-op down in the CLI side, but it makes it much easier to
integrate into MCollective, HTTP-API, and for other non-CLI users of Faces.
Reviewed-By: Max Martin <max@puppetlabs.com>
|
|
We can return a method bound to the current face instance when we access the
'when_rendering' hook, which allows us to directly call them. Make that
change, and add appropriate testing.
Reviewed-By: Max Martin <max@puppetlabs.com>
|
|
These define the API used by folks writing actions that supports their
rendering hooks. 'when_rendering' defines a helper method on the interface,
which runs the users code in their expected context.
'render_as' just sets the default rendering format; by default this is
:for_humans.
Reviewed-By: Max Martin <max@puppetlabs.com>
|
|
We tested that we could make something a default action, but we also want to
assert that we never accidentally make everything the default action.
Paired-With: Max Martin <max@puppetlabs.com>
|
|
|
|
This adds the 'description' method to the faces and actions, as well as
structured testing to ensure that the DSL works as expected.
Reviewed-By: Max Martin <max@puppetlabs.com>
|
|
Our summary documentation is used to provide single-line context to faces,
actions, and other items. To support this we hard-fail if someone tries to
use the summary to embed the long documentation, and point them to the right
place to add the extended text.
Reviewed-By: Max Martin <max@puppetlabs.com>
|
|
Running spec/unit/option_spec.rb before requiring puppet/interface
caused a circular require, and a failure.
Paired-With: Max Martin
|
|
This adds another hook into the generated wrapper, which invokes a method to
validate arguments. This is used to raise an exception when required options
have not been passed to the method.
Reviewed-By: Daniel Pittman <daniel@puppetlabs.com>
|
|
'feature/2.7.x/6978-face-and-action-options-should-have-hooks-for-various-actions' into 2.7.x
|
|
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 require that hooks take exactly three arguments; now we enforce that in the
DSL, to ensure we give good, and early, errors to users who do the wrong
thing.
Paired-With: Max Martin <max@puppetlabs.com>
|
|
Options can now add before_action and after_action blocks; these are invoked
before or after any action is invoked on the face. This allows these options
to declare common behaviour and have it automatically applied to the actions
invoked.
Option hooks have no defined order of invocation: they will run in a
completely random order. Where there are dependencies they should be on the
value of the options hash passed to the invocation, not on side-effects of the
other invocations.
You are not able to influence the arguments, options, or calling of the action
body in a before or after decorator. This is by design.
The invocation passes to the hook:
1. The action object representing this action.
2. The arguments to the action, as an array.
3. The options for the action, as a hash.
Paired-With: Max Martin <max@puppetlabs.com>
|
|
Reviewed-By: Max Martin <max@puppetlabs.com>
|
|
We now use a shebang of: #!/usr/bin/env rspec
This enables the direct execution of spec tests again, which was lost earlier
during the transition to more directly using the rspec2 runtime environment.
|
|
After some discussion we decided that most uses of the Puppet Face
infrastructure were about single faces on their own, not about the collection,
and so we were better referring to Puppet::Face[...] in code.
This implements that by translating names and references in the Ruby code to
the new, s-less, name.
|
|
This extends the summary function down through the actions themselves,
allowing us to display a useful summary to the user.
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
|
|
We had two conflicting uses of the list of available faces: in the #face?
method we were perfectly happy to create a top level key on any request, but
didn't populate the version set.
Meanwhile, in #faces we treated the set of top level keys as the absolute and
correct list of all *valid* faces, leading to pain and suffering when people
queried for an invalid face, but then expected to enumerate only valid faces.
Paired-With: Matt Robinson <matt@puppetlabs.com>
|
|
We hit another situation where we crudely flushed the internal set of faces,
but require thought we had already loaded the file defining one. This fooled
our autoloader and raised more annoying problems.
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
|
|
rspec2 automatically sets a bunch of load-path stuff we were by hand, so we
can just stop. As a side-effect we can now avoid a whole pile of stupid things
to try and include the spec_helper.rb file...
...and then we can stop protecting spec_helper from evaluating twice, since we
now require it with a consistent name. Yay.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
|
This joins the two repositories, including full history, into a single run, as
well as landing the interfaces work on the next branch ready for release.
|
|
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>
|
|
Specifying a version of `:latest` will find the most recent version of the
named interface installed in your RUBYLIB, and attempt to load that. This is
unlikely to provide a stable dependency in the future, so should be used
sparingly, acknowledging the dangers.
Reviewed-By: Daniel Pittman
|
|
Reviewed-By: Jacob Helwig
|
|
P::I#initialize now takes a name and a version (and an optional block). The
options hash has been removed, though it may be reintroduced if a legitimate
use case can be made for it (so far, it's only been used for the version
number).
Reviewed-By: Jacob Helwig
|
|
We were returning 'true', which was getting printed
unnecessarily.
Signed-off-by: Luke Kanies <luke@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>
|
|
Conflicts:
lib/puppet/interface/certificate.rb
spec/unit/application/interface_base_spec.rb
spec/unit/interface/interface_collection_spec.rb
|
|
Puppet::Interface::interface is now Puppet::Interface::define, also aliased to
Puppet::Interface::[] for convenience.
Paired-With: Nick Lewis
|
|
More information about the versioning scheme can be found at http://semver.org.
Paired-With: Nick Lewis
|
|
Reviewed-By: Nick Lewis
|
|
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
|
The specs for InterfaceCollection were clearing the list of interfaces at the
end of the spec run, which caused later specs to fail because they couldn't
re-require interfaces they needed. This fixes the InterfaceCollection specs to
save and restore the interfaces at the end of the file.
Reviewed-By: Matt Robinson
|
|
Having an instance variable on class Interface is insufficient for
Interface::Indirector. This also changes the semantics of "Interface.interface"
to handle registration and loading actions, and for "Interface.new" to only
instantiate an Interface. Thus, consumers of the API should typically use
"Interface.interface", unless they have reasons to not want an interface
automatically registered.
Paired-With: Pieter van de Bruggen
|
|
Conflicts:
lib/puppet/interface/catalog.rb
lib/puppet/interface/catalog/select.rb
lib/puppet/interface/configurer.rb
|
|
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
|
|
Ruby's namespace mechanism introduced a number of problems, including
incorrect name resolution for common and simple cases. Given that,
we've refactored back to class-level data structures with accessor
methods available.
The current method names are unlikely to be the final UI.
Reviewed-By: Daniel Pittman
|
|
Reviewed-By: Nick Lewis
|
|
This application is similar in basic functionality to the "agent" application,
but implemented in terms of interfaces. It currently will retrieve facts,
retrieve a catalog, apply the catalog, and submit a report. Options such
as noop and daemonize are still to come.
Reviewed-By: Pieter van de Bruggen
|
|
The initial merge of this branch hadn't actually been run against the full
suite of specs; a number of specs began failing shortly afterward.
Reviewed-By: Daniel Pittman
|
|
We don't have json support for node output yet.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
|
I renamed it to 'info', too.
It only showed indirector-related info, so this
makes sense.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
|
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
|
We now have an indirection_base class along
with interface_base.
I've also added some basic tests for most
of the interfaces.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
|
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>
|
