| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Running specs with rspec 2.13 caused a lot of warnings. Many of them actually
exposed preexisting bugs, the most common being a syntax error when expecting
an Exception. These are worth fixing even if we don't bump to rspec 2.13.
|
|
|
|
* 2.7.x:
Use rspec 2.11 compatible block syntax
Conflicts:
spec/integration/faces/ca_spec.rb
spec/integration/network/server/mongrel_spec.rb
spec/unit/application_spec.rb
spec/unit/face/help_spec.rb
spec/unit/network/handler/fileserver_spec.rb
spec/unit/parser/functions/create_resources_spec.rb
spec/unit/provider/nameservice/directoryservice_spec.rb
spec/unit/type/file_spec.rb
spec/unit/type_spec.rb
|
|
In rspec 2.11, expectations on a block must take the form of expect...to or
lambda...should. Other combinations of those are no longer accepted. This
commit converts all mixed cases to use expect...to, as it seems to be the
preferred syntax now.
|
|
Add `display_global_options` to Face DSL.
Add `environment`, and `modulepath` as display_global_options for existing
module face.
Add `type` for typed settings.
Add display_global_options to exising help and man faces.
|
|
Now we have passing tests on Ruby 1.9, we can make all those tags go away and
enable the full suite. Now anything that fails should be treated like a real
failure, which is reasonable since this is a real and supported platform.
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
Ruby 1.9 allows us to enforce the calling convention of face actions at load
time, rather than failing with a runtime error. This, in turn, means that we
should define actions correctly in our tests, if we expect them to work.
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
When we define an action on an older version of a Face, we must be sure to
directly load the core of that version, not just define it with the external
Action(s) that it had.
Otherwise we break our contract, which is that any core Actions for a specific
version will be available to your external Action for as long as we support
that core version.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
|
The problem was caused by the fact that the
options method returns a list of options that
treated the aliases as seperate options.
The fix is to only maintain a list of options
and not add all aliases to the options list.
|
|
2.7.x"
This reverts commit b7ee0258ab40478329c20177eda9b250f27ede18, reversing
changes made to 8fe2e555ac3d57f5b6503ffe1a5466db8d6e190a.
|
|
puppet help was reprinting every option once
for every alias that is had.
This fix involves only storing the option.name
in the @options instance var for both face and
actions options. The @options_hash still
maintains the list of options and aliases as its
keys.
Reviewed-by: Daniel Pittman (puppet-dev list)
|
|
By running:
rspec spec --tag ~@fails_on_ruby_1.9.2
We can now just run the specs that pass under Ruby 1.9. Obviously in
the long term we want to have all the specs passing, but until then we
need notification when we regress. From now on new code will be
required to pass under Ruby 1.9, and Jenkins will give us email
notification if it doesn't or if we break something that was already
working.
Reviewed-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
We used to let actions be declared without the `when_invoked` block, which was
usually a sign of either someone writing their method code direct in action
declaration, or someone forgetting to add their code at all.
This was just let silently by: the error only showed up when you finally tried
to invoke the action, and a NoMethod error was raised by the face.
...except for our own testing. We took advantage of this a whole pile of
times in there; fixing the original UI issue means fixing all those too.
Reviewed-By: Nick Lewis <nick@puppetlabs.com>
|
|
This adds the remaining documentation mechanisms to the Face instances,
allowing them to build and report correct documentation, licensing and
ownership for the help face to build on.
|
|
"Invisible glob", or "prefix", version matching means that when you specify a
version string to use you can specify as little as one version number out of
the semantic versioning spec.
Matching is done on the prefix; an omitted number is treated as "anything" in
that slot, and we return the highest matching versioned face by that spec.
For example, given the set of versions: 1.0.0, 1.0.1, 1.1.0, 1.1.1, 2.0.0
The following would be matched:
input matched
1 1.1.1
1.0 1.0.1
1.0.1 1.0.1
1.0.2 fail - no match
1.1 1.1.1
1.1.1 1.1.1
1.2 fail - no match
|
|
We used to flush the loaded face cache, but not the list of 'require' things,
which meant that these tests couldn't work with anything outside their own
setup, which is actually pretty undesirable.
Instead, port the code from the face_collection spec that handles this in a
way that makes me less inclined to weep, and which lets the surrounding code
work as designed.
|
|
Fix the conflicts over changes in my previous commit.
|
|
Now we want to support action-based rendering, it is super-hard to define the
semantics around defaulting where things are unspecified: the execution
context (CLI, HTTP, etc) vs the face, vs the action all have different
semantics.
Without solving the problem of how we express all that context and those
semantics down in the action, especially one written by a third party, this
just becomes a box of counter-intuitive and annoying semantics and edge-cases.
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>
|
|
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 adds the methods to the summary builder and runtime instance to support
setting and getting a summary of the face. This is a short description used
to summarize the purpose of the face in help output.
For example, from the help face:
"Displays help about puppet subcommands"
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
|
|
We didn't do much testing here, which was vaguely reasonable when we didn't
distinguish it from the #define method. Now they are split out we need to be
more careful about testing the right things.
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
|
|
It turns out that mocking require on objects can cause random "stack depth
exceeded" failures, usually triggered by otherwise innocent changes to load
order or the use of require in the rest of the code.
Disable the currently failing test, which needs rewriting, and let it go for
now. We need to systematically purge these problems once the build is stable.
Paired-With: Dan Bode <dan@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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
We didn't do enough input checking and sanitization, and missed some
edge-cases for naming interfaces. This adds testing, and cleans up some edge
cases to handle things better.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
|
Since constants are already being defined for each
interface, the #interface method does little but
provide another way to access the same data.
Reviewed-By: Nick Lewis
|
|
I renamed it to 'info', too.
It only showed indirector-related info, so this
makes sense.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
|
Also added a test to hopefully confirm it won't
break again.
Signed-off-by: Luke Kanies <luke@puppetlabs.com>
|
|
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>
|
