When we introduced verification of options, we forgot to handle the case that global options from the Puppet settings system could be passed to the face. This, in turn, means that the system would fail if you used any of those. This remediates that, and now these work as expected. Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
Rewrite the process of validating and updating the options to fully reflect the contract - we fail if there are unknown options passed, report nicely errors of duplicate names, pass only the canonical names to the action code, and generally enforce nicely. Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
Rather than having multiple, separate operations that modify and validate the arguments to an action, a single pass makes sense. This also means less walks across the set of data, and a few less expensive method calls in Ruby. Additionally, we work on a duplicate of the arguments hash rather than directly modifying the original. Because everything we do is at the top level key/value mapping, this is sufficient to isolate the original. While mostly theoretical, we now don't mutilate the hash passed in, so the user won't get nastily surprised by the fact that we could have done so. Reviewed-By: Pieter van de Bruggen <pieter@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>
When we first touch a Face, we load all the available Actions from disk. Given they define themselves against a specific version of a Face, they are automatically available tied to the correct version; this makes it trivially possible to locate those on demand and return them. Now, we have the ability to find and, consequently, invoke Actions on older versions of Faces. We don't load enough context, though: the older face will only have external Actions defined, not anything core. Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
As part of moving to load actions first, and their associated face, when invoked from the command line, it makes sense to push the logic for finding the action and face down into the Puppet::Face implementation. This means that we can change the logic there without needing to update the public part of the CLI implementation, and that any further facades can use the same, correct, logic to locate the action for the face. Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
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>
This implement support for options with default values, allowing faces to set those values when not invoked. This can eliminate substantial duplicate code from actions, especially when there are face-level options in use. Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
This introduces a class representing a semantic version, and implementing a few of the most common uses of them: validation, comparison, and finding the greatest available version matching a range. This refactoring also allows us to easily expand our matching of version ranges in the future, which is a big plus. Reviewed-By: Daniel Pittman
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.