| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| | |
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 had a pending test for this, but forgot to write it way back when we were
implementing the feature. Add it now.
Reviewed-By: 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>
|
| |\ \
| | |
| | |
| | |
| | | |
* ticket/2.7.x/7131-optional-arguments:
(#7131) Remove support for optional arguments to options
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As per the design decision documented in #7131, optional arguments to
options will no longer be supported. This patch causes such optional
arguments to raise an error, and tests for this behavior. Also cleaned
up some confusing use of the term "subject" in specs.
Paired-with: Daniel Pittman
|
| |/ /
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
| |
This also enables the 'help' action on the 'help'
face to serve as a default action.
Reviewed-By: Daniel Pittman
Reviewed-By: Nick Lewis
|
| |
|
|
|
|
| |
Ruby 1.9 is less forgiving about treating symbols like strings.
Reviewed-by: Daniel Pittman <daniel@puppetlabs.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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 were still looking for faces in version
directories.
No changes to testing because the current test is pending.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
Reviewed-by: Daniel Pittman <daniel@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>
|
| |
|
|
|
|
|
|
|
| |
When initializing we need to set the name and interface before we do anything
else, since the reasonable assumption for users is that those invariants are
there when their setter is called.
This allows someone to override the interface or name by misusing the call to
new, but they could already screw up by passing the wrong values, so whatever.
|
| |
|
|
|
|
|
|
|
| |
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
|
| | |
| |
| |
| | |
Puppet::SSL::Host.search (which will proxy to the new indirection) accepts an array of classes (now also class names) to limit the search. Currently, `puppet certificate list` limits itself to certificate requests to mimic the behavior of `puppet cert -l`.
|
| | |
| |
| |
| | |
The common tasks of checking the --ca-location argument and becoming a CA process if necessary (that is, acting like a master) have been abstracted into the Application where they belong.
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
| | |
| |
| |
| | |
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
No other args are used, so passing *args and shifting is unnecessary.
|
| |\|
| |
| |
| |
| |
| |
| | |
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
|
| |
|
|
|
|
|
|
|
| |
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 functionality is basically the same, but we're
no longer using caching, and we log that
it happened.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
| |
|
|
|
|
| |
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>
|
